[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] x86: improve .debug_line contents for assembly sources


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 14 Apr 2022 15:31:26 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SwbesW5ci+kI4wB9TlzPPdzmxtvc5rCl/tLeAoijQ+4=; b=ilhd2DX9kQBZlpanm/WHNRrZUsP01XYKp0Kolewut7QxdgboMhcI/cFHmKRLgf7DVhR8aP6z1xDIhf8QOFsWKwBSdBx5VXi/UKFyU2YY4sE5qpMpuVfYCG6bEak7MRRzicstOpkQsNGx+7XHm/GNmW2g9xY5fGDdUVX1COIp5kVFdfyx3CLmKQVTEdqkLm6lX4yH+2QuJUjSjEbLDfYyo4YJfaFyzwLQ9fSlW+Go07Oc9D543IgRey1S89hXmycl/YhG0sxoDMT0Q/5v0afTTclwdwPQ8DKrQNFzD9RpiGl9gJYPa+TerFsDf0akc0yafodaNYJtHgo+ToEKQyQ4bw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RMVLdB7XeTsmkz5H0I6UxpmDUWDUUaEn1XwI3UG0mufFstPfuQkPqvB4s9Rwpr70P17FGsD9251XFEx+xONR5S2/jEL0s6Cz/H91B/pGrdOHL3BNzQd4A58C2eoM93r/4M5+nFHFDWd5spsPeaGofTrQQYuYuMksVTcd6bEcs0Bi0AuycW7ltu23ptaEASxk9Ifv5oFP+Rg/X5MfhLYXoyUJJnHNBgYmvBpgFcTHj6CuDd28ufTQ7AhXHeSOznk02P8xeKyH2xAe7uL1rztFd6jE5lCts9u3Tt3SGECIngnwY5bm2RMvk8S7qC0c/mNAFDh/ZUM3P/C7KWMDUe5+cw==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 14 Apr 2022 13:31:55 +0000
  • Ironport-data: A9a23:S6WxnKAUU9HZwRVW/z7jw5YqxClBgxIJ4kV8jS/XYbTApDx2hTRWz WofCDzQb/qOajf0edh+bo2yo0gEv5SHxodiQQY4rX1jcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuOU5NXsZ2YgHWeIdA970Ug5w7Jg3tYx6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPhNi 4QQnqG8QDsqZKHAkdxNczp3KyBhaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguw5K8bmJsUHs2xIxjDFF/c2B5vERs0m4PcGjWxu3JgQR54yY eIzbSczTRjsPCFUP01NGbk4hfyxi3rGJmgwRFW9+vNsvjm7IBZK+KfpGMrYfJqNX8o9tlaVo CfK8nr0BjkeNceD0nyV/3S0nOjNkCjnHoUIG9WQ9PRnnVmSzWw7EwANWB2wpvzRt6Klc4sBc QpOoHNo9PVsshzwJjXgY/GmiELH70M3ZtZZL+5g5A2E8vr0wCmhB3dRG1atd+canMMxQDUr0 HqAkNXoGSFjvdWpdJ6NyluHhWjsYHZIdAfucQdBFFJYuIe7/OnfmzqVFr5e/LiJYsoZ8N0a6 xSDt2AAiroalqbnPI3rrAmc01pASnUkJzPZBzk7vEr4tmuVh6b/PuREDGQ3C94afe51qXHb4 hA5dzC2trxmMH10vHXlrB8xNL+o/e2ZFzbXnERiGZIsnxz0pSLyLdoIuW8ifxw0WirhRdMPS BWC0e+2zMUNVEZGkIctO97hYyjU5fWI+SvZugD8MYMVP8kZmP6v9yByf0+At10BY2B3+ZzTz ayzKJ72ZV5DUPwP5GPvG481jO96rghjlDi7bc2qkHyaPU+2OSf9pUEtawDVMIjULcqs/W3oz jqoH5LTlU4OAbGkP3G/HEx6BQliEEXXzKve8qR/XuWCPhBnCCcmDfrQyqkmYItrg+JekeKgw 513chYwJIbX7ZEfFTi3Vw==
  • Ironport-hdrordr: A9a23:Iqzgaq3cN69pkUgWRohXDgqjBVZyeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5OEtBpTiBUJPwJ0800aQFnLX5Wo3SIDUO2VHYVr2KiLGC/9SOIVyaygcw79 YFT0E6MqyOMbEYt7eL3ODbKadZ/DDvysnB7o2yvhQdLz2CKZsQlDuRYjzrY3GeLzM2fKbReq Dsgfau8FGbCAoqh4mAdzI4dtmGg+eOuIPtYBYACRJiwA6SjQmw4Lq/NxSDxB8RXx5G3L9nqA H+4kHEz5Tml8v+5g7X1mfV4ZgTsNz9yuFbDMjJrsQOMD3jhiuheYwkcbyfuzIepv2p9T8R4Z PxiiZlG/42x2Laf2mzrxeo8w780Aw243un8lOciWuLm72OeBsKT+56wa5JeBrQ7EQt+Ptm1r hQ4m6fv51LSTvdgSXU/bHzJl9Xv3vxhUBnvf8YjnRZX4dbQqRWt5Yj8ERcF4pFND7m6bogDP JlAKjnlblrmGuhHjDkV1RUsZ+RtixZJGbFfqFCgL3Y79FupgE586NCr/Zv20vp9/oGOu55Dq r/Q+BVfYp1P70rhJJGdZQ8qPSMexnwqDL3QSuvyAfcZek600ykke+C3Fxy3pDsRKA1
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 14, 2022 at 02:52:47PM +0200, Jan Beulich wrote:
> On 14.04.2022 14:40, Roger Pau Monné wrote:
> > On Tue, Apr 12, 2022 at 12:27:34PM +0200, Jan Beulich wrote:
> >> While future gas versions will allow line number information to be
> >> generated for all instances of .irp and alike [1][2], the same isn't
> >> true (nor immediately intended) for .macro [3]. Hence macros, when they
> >> do more than just invoke another macro or issue an individual insn, want
> >> to have .line directives (in header files also .file ones) in place.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >>
> >> [1] 
> >> https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=7992631e8c0b0e711fbaba991348ef6f6e583725
> >> [2] 
> >> https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=2ee1792bec225ea19c71095cee5a3a9ae6df7c59
> >> [3] 
> >> https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=6d1ace6861e999361b30d1bc27459ab8094e0d4a
> >> ---
> >> Using .file has the perhaps undesirable side effect of generating a fair
> >> amount of (all identical) STT_FILE entries in the symbol table. We also
> >> can't use the supposedly assembler-internal (and hence undocumented)
> >> .appfile anymore, as it was removed [4]. Note that .linefile (also
> >> internal/undocumented) as well as the "# <line> <file>" constructs the
> >> compiler emits, leading to .linefile insertion by the assembler, aren't
> >> of use anyway as these are processed and purged when processing .macro
> >> [3].
> >>
> >> [4] 
> >> https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=c39e89c3aaa3a6790f85e80f2da5022bc4bce38b
> >>
> >> --- a/xen/arch/x86/include/asm/spec_ctrl_asm.h
> >> +++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h
> >> @@ -24,6 +24,8 @@
> >>  #include <asm/msr-index.h>
> >>  #include <asm/spec_ctrl.h>
> >>  
> >> +#define FILE_AND_LINE .file __FILE__; .line __LINE__
> > 
> > Seeing as this seems to get added to all macros below, I guess you did
> > consider (and discarded) introducing a preprocessor macro do to the
> > asm macro definitons:
> > 
> > #define DECLARE_MACRO(n, ...) \
> > .macro n __VA_ARGS__ \
> >     .file __FILE__; .line __LINE__
> 
> No, I didn't even consider that. I view such as too obfuscating - there's
> then e.g. no visual match with the .endm. Furthermore, as outlined in the
> description, I don't think this wants applying uniformly. There are
> macros which better don't have this added. Yet I also would prefer to not
> end up with a mix of .macro and DECLARE_MACRO().

I think it's a dummy question, but why would we want to add this to
some macros?

Isn't it better to always have the file and line reference where the
macro gets used?

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.