On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich <ayerm...@fb.com> wrote:
> > > ------------------------------ > *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> > 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. > [Alex] Well if there is no consensus maybe clang can trail blaze. 🙂 > My concern with doing so is both that GCC might not make the same decision, leading to differences in flag semantics (and my other concerns about the available options that lean towards the -g* style naming and the ambiguities around composability or implied -g in general and in particular with the likely names here and how close they are to existing names that do imply -g, hence my personal preference towards the -f names). Might end up going with the -f names out of a combination of my desire for clear designation of composability, and sidestepping the issue of GCC compatibility in the future if GCC's going to pick a -g name and semantics (implied -g or otherwise) anyway. This does mean I/we/clang loses a chance to perhaps somewhat more heavily (than just my words here) influence GCC's flag choice (eg: by Clang choosing the -g* naming and making it composable, for instance), but avoids the chance of divergent behavior between the two compilers, or breaking backwards compatibility to maintain compatibility. All up I just don't have great feelings about any of the paths forward, really. I think -fdwarf32/64 is the better option for users, that -gdwarf32/64 implying -g would be unfortunate (composability is valuable) and -gdwarf32/64 being composable would be pretty confusing to users given -gdwarf-N isn't composable & they are very similar flags/spellings (similarly for -g32/64 compared to -gN). Sorry, just going around in circles a bit, I guess this may be a better summary: If I had to pick a -g flag/semantic for this, I guess I'd pick -gdwarf32/64 without implied -g. I'd pick that if I knew GCC would implement it to match - but if GCC might go either way on implied -g, I think I'd rather avoid changing the semantics of the flag later on & use a different name GCC isn't likely to define different semantics for (and I'd probably pick -fdwarf32/64). - Dave >
