ayermolo 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. ---------------- dblaikie wrote: > 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)) In the DWARFV5-64 pdf it says 64 bit support has no patches and is after DWARF5. Although it's not clear if they are talking about DWARF64 support for V5 or in general. I have not hacked our build system to use gcc for builds that can overflow debug_info. I scanned through gcc code and was only able to find references to dwarf 64 in go library, and in dwarf2out.c. In latter it relies on DWARF_OFFSET_SIZE macro. I don't quite understand the "all [CU] units must agree" part either. From DWARF perspective we are free to match on CU level DWARF32/64, and consumer are free not to do anything beyond that. So if overflow occurs, will so be it. What we are trying to do in linker with sorting is being "nice" to the users, and kind of going beyond what spec requires. Sounds like no conclusion was reached on their side, but only one of them -gdwarf64 follows naming convention of other debug flags. > * -fdwarf64/-fdwarf32 > * or -gdwarf32 or -gdwarf64 > * or -gdbdwarf=32/64 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90507/new/ https://reviews.llvm.org/D90507 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
