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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.11.15 at 16:07, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/11/15 14:45, Jan Beulich wrote:
>>>>> 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.
> 
> Needless cluttering is indeed bad.  However, the effect here is a
> misleading stack trace.
> 
> As the entire point of the symbol table is to generate usable
> information in situations like this, I don't see this as an issue.
> 
>>  If anything I'd agree to adding a label to the start of
>> subsection 1 (or .fixup),
> 
> How is this suggestion any different to what I have presented?  Each
> unlikely section still gets a non-local label.

Your proposal produces one label per code addition to the unlikely
section. My proposal generates just one label, no matter how many
contributions to the section get done in a compilation unit.

>> 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).
> 
> All UNLIKELY() sections have content, as they are manually created.  Or
> have I missed something?

I guess you take each .subsection as representation of a separate
section, while I take only their set per compilation unit as one (and
this being a sub-section means even that is still to wide a term).

Jan


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