[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 18:02:17 +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=GWucSSDjkz4advjswNkqcdcVCIrU5eHt8e/jefXM3KE=; b=koE6/wLCQq3XXXjLIQpqYrF9hVSPDF+dn1frjceRtQGp4ZZQx+ht70r2OsHUSl21O5S4vs2DptMIb1dJcSckxJgTu9qDoQIh9j+BhkOFbx4WRtaVcPegTSzfAQ3yy9JpOa5pZLZA3NXwF2V8fyYqIZJpTiyFeHIGsGkT491tv5Cip44Rmpisvp6RdykhuZUfVBVtYV9ihj9Js2i31uNuPv4S+/gpvs9Qno1xijGm6rs/D2pyIAN9coN85JI0nHUCoXhEpwZATWheYbc+vb855Jka5xy/s2kvcVMBiT75u5OVcucAeq2SVxM2cGN3SjDyVGOjbDH7cZDTA00/0sfWxw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aJi5YU0HWid8ojPtaLqXmlSSBB56iFZF7USgyF50/qmCFjVDeF/pKZA4EvTclfIYHeJTdg5JaaFV7gADfmFN5vmd+LWLhSqgS1wtS05HrEu2vdGeNaetGNzC2nMdIDV+BET3GUoV5Fof+OFtETBLEpWBwZNL72cRMWOQBe3vwFNpvhqcVTOhlTaPZSN4LMR43lc/kcQGqk7WFQyeUHWzzOaGrsTCTC8I1s1k3JpdKqgdwzO8ONGYz9UALSda6xQB3yEr3RXwcOZnhYOc+269PNyzlhA//I7jUmfzlx5sPNE90f4FP5kqjNLZGAmVEjCjzZOhuwYMxicyfXERKUnanA==
  • Authentication-results: esa3.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 16:02:34 +0000
  • Ironport-data: A9a23:tpXFcqlFUO2JblfG5UOvEPro5gyWJkRdPkR7XQ2eYbSJt1+Wr1Gzt xJNXj+HPf2IN2L0ft0jYNyz8htQuZ6Bm9Q1QFZkrSsxHiMWpZLJC+rCIxarNUt+DCFioGGLT Sk6QoOdRCzhZiaE/n9BCpC48T8kk/vgqoPUUIYoAAgoLeNfYHpn2EoLd9IR2NYy24DlWl/V4 7senuWEULOb828sWo4rw/rrRCNH5JwebxtB4zTSzdgS1LPvvyF94KA3fMldHFOhKmVgJcaoR v6r8V2M1jixEyHBqD+Suu2TnkUiGtY+NOUV45Zcc/DKbhNq/kTe3kunXRa1hIg+ZzihxrhMJ NtxWZOYYgUyBJ/nxuEnDgBVER5VAJUF85LXGC3q2SCT5xWun3rExvxvCAc9PJEC+/YxCmZLn RAaAGlTNFbZ3bvwme/lDLk37iggBJCD0Ic3oHZvwCufFf87aZvCX7/L9ZlT2zJYasVmQ6aPO JVEMWUHgBLoRTwWYF0lArcHjeK1uULvWj5Jo1eluv9ii4TU5FMoi+W8WDbPQfSVQe1Fk0Deo XjJl0zpDxdfONGBxD6t9nO3mvSJjS79QJgVFrCz6rhtmlL77m4ZBQASVFC7ieKkkUP4UNVaQ 3H44QJ38/J0rhbyCICgAVvo+xZooyLwRfJ7EfYA2irTz5CJ+gubOUM5dn1KRcwf4ZpeqSMR6 neFmNbgBDpKubKTSG6A+rr8kQ5eKRT5PkdZO3ZaEFJtD83L5dhq00mRFooL/Lud1IWdJN3m/ 9ydQMHSbZ03hNVD6ai09Euvb9mE9smQFV5dCuk6swuYAuJFiGyNOtTABbvzt68owGOlor+p5 ilsdy+2tr5mMH11vHbRKNjh5Znwjxp/DBXSgER0A74q/Cm39niocOh4uW8idRczap9aJWSyP Sc/XD+9ArcJbRNGioctPeqM5zkCl/C8RbwJqNiJBjaxXnSBXFDep3w/DaJh92vsjFItgckC1 WSzKq6R4YIhIf0/llKeHr5FuZdyn3xW7T6DFPjTkkX8uZLDNSH9dFvwGAbXBgzPxPjf+1u9H hc2H5bi9iizp8WnO3eMoN9Pdw1SRZX5bLivw/Fqmie4ClMOMEkqCuPLwKNnfIpgnq9PkfzP8 G37UUhdoGcTT1WZQelWQhiPsI/SYKs=
  • Ironport-hdrordr: A9a23:9eL9Zq/MNP2iITZlV3Juk+E6db1zdoMgy1knxilNoENuHfBwxv rDoB1E73LJYVYqOU3Jmbi7Sc69qFfnhORICO4qTMqftWjdyRCVxeRZg7cKrAeQeREWmtQtsJ uINpIOdOEYbmIK/PoSgjPIaurIqePvmMvD5Za8854ud3ATV0gJ1XYGNu/xKDwReOApP+tcKH LKjfA32AZINE5nJviTNz0gZazuttfLnJXpbVovAAMm0hCHiXeN5KThGxaV8x8CW3cXqI1Su1 Ttokjc3OGOovu7whjT2yv66IlXosLozp9mCNaXgsYYBz3wgkKDZZhnWZeFoDcpydvfo2oCoZ 3pmVMNLs5z43TeciWcpgbs4RDp1HIU53rr2Taj8AzeiP28YAh/J9tKhIpffBecwVEnpstA3K VC2H/cn4ZLDDvb9R6NqOTgZlVPrA6ZsHAimekcgzh0So0FcoJcqoQZ4Qd8DIoAJiTn84oqed MeQP003MwmMG9yUkqp/lWGmLeXLzcO91a9MwU/U/WuonZrdCsT9Tpb+CQd9k1wgK7VBaM0ot gsCZ4Y542mfvVmHZ6VO91xM/dfKla9Ny4kY1jiaGgOKsk8SgfwQtjMkfEI2N0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 14, 2022 at 04:15:22PM +0200, Jan Beulich wrote:
> On 14.04.2022 15:31, Roger Pau Monné wrote:
> > 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?
> 
> Like said in the description, a macro simply invoking another macro,
> or a macro simply wrapping a single insn, is likely better to have
> its generated code associated with the original line number. Complex
> macros, otoh, are imo often better to have line numbers associated
> with actual macro contents. IOW to some degree I support the cited
> workaround in binutils (which has been there for many years).

Seems a bit ad-hoc policy, but it's you and Andrew that mostly deal
with this stuff, so if you are fine with it.

Acked-by: roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks, Roger.



 


Rackspace

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