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: > > 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) Ah, thanks for the context. My takeaway it's a mess. :) Personally I find it more confusing that there are debug options that start with -f and -g, rather then that some -g enable debug output. When I look at documentation I just want to have see all the related options grouped in one area/one prefix, but that's just how my brain works. That being said I don't have particular strong opinion about naming convention of this flag. Judging from that conversation, maybe there is some preference for -f, but mainly it was a big push against changing an option after it was introduced and proliferated. 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
