________________________________ From: David Blaikie <dblai...@gmail.com> Sent: Wednesday, December 2, 2020 1:12 PM To: Alexander Yermolovich <ayerm...@fb.com> Cc: Richard Biener <richard.guent...@gmail.com>; Jakub Jelinek <ja...@redhat.com>; Mark Wielaard <m...@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikud...@accesssoftek.com <ikud...@accesssoftek.com>; mask...@google.com <mask...@google.com> Subject: Re: DWARF64 gcc/clang flag discussion
On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>> wrote: ________________________________ From: David Blaikie <dblai...@gmail.com<mailto:dblai...@gmail.com>> Sent: Tuesday, December 1, 2020 10:33 AM To: Alexander Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>> Cc: Richard Biener <richard.guent...@gmail.com<mailto:richard.guent...@gmail.com>>; Jakub Jelinek <ja...@redhat.com<mailto:ja...@redhat.com>>; Mark Wielaard <m...@klomp.org<mailto:m...@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com> <ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com>>; mask...@google.com<mailto:mask...@google.com> <mask...@google.com<mailto:mask...@google.com>> Subject: Re: DWARF64 gcc/clang flag discussion On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>> wrote: ________________________________ From: David Blaikie <dblai...@gmail.com<mailto:dblai...@gmail.com>> Sent: Monday, November 30, 2020 12:09 PM To: Alexander Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>> Cc: Richard Biener <richard.guent...@gmail.com<mailto:richard.guent...@gmail.com>>; Jakub Jelinek <ja...@redhat.com<mailto:ja...@redhat.com>>; Mark Wielaard <m...@klomp.org<mailto:m...@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com> <ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com>>; mask...@google.com<mailto:mask...@google.com> <mask...@google.com<mailto:mask...@google.com>> Subject: Re: DWARF64 gcc/clang flag discussion On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>> wrote: Thank you David for driving the conversation, sorry I was on vacation. All good - really appreciate everyone chipping in whenever/however they can! I guess discussion is from perspective of having both flags gdwarf32/gdwarf64. In which case it's a valid question on whether they should imply -g like -gdwarf-#. But can this be viewed as only a -gdwarf64 flag, that is a qualifier to other debug flags that enable debug information? DWARF spec says that 32bit should be a default, and 64bit should be used rarely (paraphrasing). So when user enabled debug information the default expectation is that it will be 32bit. There is no real need for a flag to say "I want debug information, and I want it 32bit". I'm not quite with you here, I think. I believe it's important to be able to opt into and out of things at any point on the command line - because of how complex build systems build up command lines. You might have a -gdwarf64 set as a project default, but for some reason want to opt into -gdwarf32 in other parts (perhaps you're building the debug info for your interface library you intend to ship to clients who might only have DWARF32 support, but your library is big and needs DWARF64 for the rest). A general architectural principle of most command line arguments to the compiler is that they can be opted into/out of fairly symmetrically (hence all the -*no-* variant flags). [Alex] Ah I see, good point. On the other hand, 64bit DWARF format must be enabled. So from users perspective it's "I want debug information enabled for particular DWARF version and level, oh and I want it to be 64bit". But there's also the possibility of wanting to turn on DWARF64 for any debug info in your build, but not necessarily wanting to turn on debug info while doing so. Eg: you have a big build system, with a variety of users and flags all over the place - maybe users opting in to -g2 on some files and -g1 on others, and/or under different build modes. And the project as a whole is reaching the DWARF64 tipping point and you'd like to say "if we're generating DWARF, make it DWARF64". We've recently encountered this sort of situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we had this situation where there's a big code base/build system with many users, many uses of different -gN-type flags and it'd be impractical to go and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we added -fdebug-default-version=N (I might be misremembering the spelling) to Clang to support this use case of "If we're generating DWARF, make it DWARFv5") [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable debug generation, but if it is enabled it will be 64bit. A "qualifier" of sorts. OK. My concern there, though I think it's the preferable semantics for the -gdwarf64 flag when considered in isolation, is now -gdwarf64 and -gdwarf-5 would have some fairly subtly different semantics (the latter enables debug info and the former does not) in contrast to how close their spelling is. (in addition to their general similarly maybe being a source of confusion - even if the numbers aren't close to each other) [Alex] That is a good point, but I guess broader question is if precedence is not good, should we follow it? If it's clearly documented, might be OK. As my professor Brian Harvey said many, many, many moons ago during my undergrad: "RTFM". If my understanding of exchange on this thread is correct, there doesn't seem to be a consensus on this point. Re: lacking consensus: yep. That's my understanding. Admittedly my sort of wedge take on this is - why not use -f flags that don't have the ambiguity/overlap with "maybe it enables debug info too". (& maybe we could use -fdwarf32/64 in Clang, to avoid implementing -gdwarf32/64 with a difference in behavior in terms of also-enables-emission - then implement whatever semantics GCC ended up picking) - well, "why not" because of the general take that debug info flags should be "-g", fair enough. So, yeah, I'm still pretty undecided about how Clang should move forward with this in the immediate future. [Alex] Well if there is no consensus maybe clang can trail blaze. 🙂 - Dave
