Re: [Xen-devel] [PATCH 5/6] xen/x86: Avoid using local labels for UNLIKELY() regions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.10.15 at 20:59, <andrew.cooper3@xxxxxxxxxx> wrote:
> Using local labels causes the stack trace to use the last non-local
> label emitted by the compiler in the translation unit, which is almost
> always unrelated.
> 
> e.g. A (contrived debug) example switches from:
> 
>   (XEN) ----[ Xen-4.7-unstable  x86_64  debug=y  Not tainted ]----
>   (XEN) CPU:    0
>   (XEN) RIP:    e008:[<ffff82d0801961e2>] 
> asm_domain_crash_synchronous+0x44/0x4c
>   ...
>   (XEN) Xen call trace:
>   (XEN)    [<ffff82d0801961e2>] asm_domain_crash_synchronous+0x44/0x4c
>   (XEN)    [<ffff82d080114bdf>] handle_keypress+0xa4/0xd9
> 
> to:
> 
>   (XEN) ----[ Xen-4.7-unstable  x86_64  debug=y  Not tainted ]----
>   (XEN) CPU:    0
>   (XEN) RIP:    e008:[<ffff82d0801961e2>] unlikely.vmptrld.921+0/0x8
>   ...
>   (XEN) Xen call trace:
>   (XEN)    [<ffff82d0801961e2>] unlikely.vmptrld.921+0/0x8
>   (XEN)    [<ffff82d080114bdf>] handle_keypress+0xa4/0xd9
> 
> which is far more relevant when identifying %eip.

I disagree; I specifically used local labels here to avoid cluttering the
symbol table. If anything I'd agree to adding a label to the start of
subsection 1 (or .fixup), but it's not clear how emitting such labels
could be avoided when that section is empty (such labels would clash
with whatever label is first in the next compilation unit). Maybe we
could discard them in the symbols processing tool if their address
matches another symbol.

> Additionally, correct the inclusion of the tag parameter in the C UNLIKELY
> blocks, to use the passed tag, rather than a literal ".tag".

This part I agree with of course, and would therefore like to as for this
to be split off.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel