[PATCH] D90507: Adding DWARF64 clang flag: -gdwarf64

Thu Nov 19 13:15:23 PST 2020

dblaikie added inline comments.

================
Comment at: clang/include/clang/Basic/CodeGenOptions.def:35
 CODEGENOPT(AsmVerbose        , 1, 0) ///< -dA, -fverbose-asm.
+CODEGENOPT(Dwarf64           , 1, 0) ///< -gdwarf64.
 CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
----------------
ayermolo wrote:
> ikudrin wrote:
> > dblaikie wrote:
> > > Is there any precedent to draw from for this flag name? (Does GCC support DWARF64? Does it support it under this flag name or some other? (similarly with other gcc-like compilers (Intel's? Whoever else... )))
> > It looks like we are pioneering in that area. To me, the proposed name looks consonant with other debug-related switches.
> I didn't see any dwarf64 flags in gcc:
> https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
> 
> I tried to follow clang convention for other dwarf flags.
Huh - tried making really big binaries or anything (or checking the GCC source) to see if it does it implicitly under some conditions?
Hmm - looks like this maybe came up at the Linux Plumbers Conference & the suggested flag was -fdwarf64/32: https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf (this avoids the "does g imply debug info" and avoids the subtle distinction between "-gdwarf64 and -gdwarf-N" the presence of the '-' changing the meaning of the number quite significantly). Though hardly authoritative
https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt - seems some other options were (are?) under consideration too. Might be worth touching base with the folks involved in those discussions to see where they're at with regard to naming/support?

(they also touch on the "all units must agree" issue - so not sure if the same folks involved in those discussions have also been included in the discussions around debug info 32/64 sorting as another approach that may avoid the "all units must agree" constraint (I assume that's the reason they had that constraint))

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90507