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: > 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 > > > > > only one of them -gdwarf64 follows naming convention of other debug flags. There are many debug flags that don't use the '-g' prefix. (-fdebug-types-section comes to mind, but I think - this was discussed in depth earlier this year with regards to the -gsplit-dwarf flag, for instance: https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html - though at least the DWARF64 flag doesn't have the legacy that -gsplit-dwarf has that complicates things further there) 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
