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. > > 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". 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". > > This also helps to avoid the scenario if user explicitly specifies debug > level. The gcc documentation says > "If you use multiple -g options, with or without level numbers, the last such > option is the one that is effective." > With complex, like buck, build systems with various config files, and hard > coded overrides that's just asking to end up with debug level that might not > be what user expects. > > Thank You > Alex
Personally I also prefer that -gdwarf64 does not implies debug info emission, and wish we can continue using -g for future debug options (not having to abandon -g just because a few -g have the undesired side effect). The usage of -gdwarf64 is niche. If the side effect of -gdwarf-N, -ggdb, -gstabs, -gxcoff, etc is clearly documented on https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html I hope -gdwarf64 not implying debug info emission is fine. Clang from 10.0 onwards supports -fdebug-default-version (https://reviews.llvm.org/D69822) for a -gdwarf-N variant which does not imply debug info emission. > > ________________________________ > From: David Blaikie <dblai...@gmail.com> > Sent: Wednesday, November 25, 2020 1:46 PM > To: Richard Biener <richard.guent...@gmail.com> > Cc: Jakub Jelinek <ja...@redhat.com>; Mark Wielaard <m...@klomp.org>; > gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikud...@accesssoftek.com > <ikud...@accesssoftek.com>; Alexander Yermolovich <ayerm...@fb.com>; > mask...@google.com <mask...@google.com> > Subject: Re: DWARF64 gcc/clang flag discussion > > On Wed, Nov 25, 2020 at 1:22 AM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblai...@gmail.com> wrote: > > > > > > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <ja...@redhat.com> wrote: > > > > > > > > On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote: > > > > > Hi, > > > > > > > > > > On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote: > > > > > > On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek <ja...@redhat.com> > > > > > > wrote: > > > > > > > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, > > > > > > > even > > > > > > > when DWARF 32 is released in 81 years from now or how many, it > > > > > > > would > > > > > > > use -gdwarf-32. > > > > > > > > > > > > Works for me. Let's go with -gdwarf32/64. > > > > > > > > > > I don't have a strong opinion, so if that is the consensus, lets go > > > > > with that. The only open question (which I wanted to avoid by picking > > > > > -f...) is whether it enables generating debuginfo as is normal when > > > > > using any -goption, or whether you need another -goption to explicitly > > > > > turn on debuginfo generation when using -gdwarf32/64? My preference > > > > > would be that any option starting with -g enables debuginfo generation > > > > > and no additional -g is needed to keep things consistent. > > > > > > > > I think we lost that consistency already, I think -gsplit-dwarf has been > > > > changed quite recently not to imply -g. > > > > > > My understanding was that that change hasn't gone in at this point, in > > > part because of the issue of changing the semantics of an existing > > > flag and discussions around whether -g implies debug info. Could you > > > confirm if this change has been made in GCC? as it may be important to > > > make a similar change in Clang for consistency. > > > > > > Not that Split DWARF would be the first example of -g flags that don't > > > imply -g. (-ggnu-pubnames, I think, comes to mind) > > > > > > > That said, for -gdwarf32/64, I think it is more sensible to enable debug > > > > info than not to. > > > > > > Given my (& I think others on both GCC and Clang from what I gathered > > > from the previous threads) fairly strong desire to allow selecting > > > features without enabling debug info - perhaps it'd make sense for > > > Clang to implement -fdwarf32/64 and then can implement -gdwarf32/64 > > > for compatibility whenever GCC does (without implementing -gdwarf32/64 > > > with potentially differing semantics than GCC re: enabling debug info) > > > > > > Seems these conversations end up with a bunch of different > > > perspectives which is compounding the inconsistencies/variety in > > > flags. > > > > > > If there's general agreement that -g* flags should imply -g, maybe we > > > could carveout the possibility then that -f flags can affect debug > > > info generation but don't enable it? For users who want to be able to > > > change build-wide settings while having potentially > > > per-library/per-file customization. (eg: I want to turn down the debug > > > info emission on this file (to, say, -gmlt) but I don't want to force > > > debug info on for this file regardless of build settings) > > > > I don't think that all -g switches have to enable debuginfo generation. > > Any thoughts on this case - whether -gdwarf32/-gdwarf64 should imply -g? > > > Historically the -g flags selecting a debuginfo format did and I guess > > we need to continue to do that for backward compatibility (-gdwarf, > > -gstabs, etc.). > > -gdwarf-N sort of falls under this category, at least for backwards > compatibility - though whether it "selects a debuginfo format" might > be a bit open to interpretation. Where does -gdwarf32/-gdwarf64 fall > on that spectrum for you? I guess the important part is compatibility, > not whether it selects a debug info format or does something else. > There's no need for mechanical compatibility (though possibly for > human compatibility - having -gdwarf-4 enable -g but -gdwarf32 not > enable -g seems fairly subtle to me) here, but some folks on this > thread suggest -gdwarf32 should enable -g (Jakub and Jeff). > > > All other -g flags should not enable debug and some > > clearly don't, like -gcolumn-info which is even enabled by default. > > Also -gno-pubnames does not disable debug. > > > > From looking at the source the following options enable debug: > > > > -g > > -gN > > -gdwarf > > -gdwarf-N > > -ggdb > > -gstabs > > -gstabs+ > > -gvms > > -gxcoff > > -gxcoff+ > > > > all others do not. And yes, the -gsplit-dwarf change went in. > > Oh. Seems a pity from a backwards (& sidewards with clang - though > we'll probably update ours to match to reduce that problem) > compatibility standpoint, but good to know! > > - Dave -- 宋方睿
