From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 5/6] xen/x86: Avoid using local labels for UNLIKELY() regions Date: Wed, 4 Nov 2015 15:07:10 +0000 Message-ID: <563A1F1E.4070603@citrix.com> References: <1446235164-29421-1-git-send-email-andrew.cooper3@citrix.com> <1446235164-29421-6-git-send-email-andrew.cooper3@citrix.com> <563A281E02000078000B1C09@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <563A281E02000078000B1C09@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 04/11/15 14:45, Jan Beulich wrote: >>>> On 30.10.15 at 20:59, 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:[] >> asm_domain_crash_synchronous+0x44/0x4c >> ... >> (XEN) Xen call trace: >> (XEN) [] asm_domain_crash_synchronous+0x44/0x4c >> (XEN) [] handle_keypress+0xa4/0xd9 >> >> to: >> >> (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Not tainted ]---- >> (XEN) CPU: 0 >> (XEN) RIP: e008:[] unlikely.vmptrld.921+0/0x8 >> ... >> (XEN) Xen call trace: >> (XEN) [] unlikely.vmptrld.921+0/0x8 >> (XEN) [] 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. > 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? > 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. I will see about this, after we have agreed on the other bits. ~Andrew