On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayerm...@fb.com> wrote:
> > > ------------------------------ > *From:* David Blaikie <dblai...@gmail.com> > *Sent:* Tuesday, December 1, 2020 10:33 AM > *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 Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayerm...@fb.com> > wrote: > > > > ------------------------------ > *From:* David Blaikie <dblai...@gmail.com> > *Sent:* Monday, November 30, 2020 12:09 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 Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <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. - Dave
