On 03/22/2017, 08:25 AM, Ingo Molnar wrote: > > * Pavel Machek <pa...@ucw.cz> wrote: > >> Hi! >> >>> -ENTRY(saved_rbp) .quad 0 >>> -ENTRY(saved_rsi) .quad 0 >>> -ENTRY(saved_rdi) .quad 0 >>> -ENTRY(saved_rbx) .quad 0 >>> +SYM_DATA_START(saved_rbp) .quad 0 >>> +SYM_DATA_START(saved_rsi) .quad 0 >>> +SYM_DATA_START(saved_rdi) .quad 0 >>> +SYM_DATA_START(saved_rbx) .quad 0 >> >> Does it make sense to call it SYM_DATA_*START* when there's no >> corresponding end? > > That looks like a bug - I think we should strive for them to always be in > pairs. > > Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated' > SYM_*_START() uses? This could be done by emitting debug data into a special > section and then analyzing that section for unpaired entries. The section can > be > discarded in the final link, it won't show up in the kernel image.
It should be easier than that. No introduction of other info needed -- every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should be a bug now. > We don't ever nest symbols, right? AFAI could see so far, correct. >> Plus... it looks like saved_rsi (and friends) are only used inside >> wakeup_64.S. Could we just delete the "ENTRY" annotations? > > That appears to make sense as well. +1, will fix this. thanks, -- js suse labs _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
