[PATCH] D81144: [MC] Generate .debug_line in the 64-bit DWARF format [2/7]

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 5 01:03:43 PDT 2020


jhenderson added a subscriber: thopre.
jhenderson added a comment.

Supporting the asm code path sounds necessary to me too. Once one object starts using DWARF64, I'm pretty sure all objects should switch for a reliable build system, although it's probably not strictly required. As discussed by others, if huge.o comes before asm.o in the link, asm.o's section offsets will need to be 64-bit, even if its length fields don't need to be. Also, beware that some people do crazy things and auto-generate source, usually C/C++ source, but I don't see why they couldn't do it for assembly too, and they do actually want debug information for that quite often too. This auto-generated source can often end up massive, with corresponding large debug data sizes.



================
Comment at: llvm/lib/MC/MCDwarf.cpp:487
+  emitAbsValue(*MCOS,
+               MakeStartMinusEndExpr(context, *LineStartSym, *LineEndSym,
+                                     UnitLengthBytes),
----------------
ikudrin wrote:
> jhenderson wrote:
> > Aside: I think this function may be misnamed - shouldn't it be `MakeEndMinusStartExpr`?
> Looks like you are right. Would you like to prepare the patch?
I would, but I already have too many patches in progress to keep track of, in relation to my debug line work at the moment, so if somebody else is able to fix it, that would be great.


================
Comment at: llvm/test/MC/ELF/gen-dwarf64.s:20
+# DUMP5-NEXT: file_names[  0]:
+# DUMP5-NEXT:            name: .debug_line_str[0x00000000[[FILEOFF:[[:xdigit:]]{8}]]] = "[[FILE:.+]]"
+# DUMP5-NEXT:       dir_index: 0
----------------
ikudrin wrote:
> jhenderson wrote:
> > FileCheck has relatively recently been extended to improve numeric variable capturing. You can change this line to something like:
> > 
> > `name: .debug_line_str[0x00000000[[#FILEOFF:]]] = "[[FILE:.+]]"`
> > 
> > and the usage to: `0x[[#FILEOFF]]`.
> > 
> > Beware that there are some issues relating to leading zeros that I can't quite remember the details of.
> I believe the feature would be great if there was a need for an expression, but here we can just compare exact strings.
> 
> With numeric substitutions, the first match would be something like `0x[[#%x,FILEOFF:]]`, and the usage would look like `0x{{0*}}[[#FILEOFF]]`. To my taste, the current variant is much simpler. Moreover, the current variant shows the exact number of hex digits we expect in the dump, which is, AFAIK, impossible with numeric substitutions.
Wanting to check the exact number of digits sounds reasonable to me. Possibly deserves an extension to the FileCheck expression parser at some point too. @thopre - thoughts on that? It seems related to our previous discussion about leading zeros too.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81144/new/

https://reviews.llvm.org/D81144





More information about the llvm-commits mailing list