Re: DWARF64 gcc/clang flag discussion

[Alexander Yermolovich <ayermolo@fb.com>]

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

________________________________
From: David Blaikie <dblaikie@gmail.com>
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; Alexander Yermolovich <ayermolo@fb.com>; maskray@google.com <maskray@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion

On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@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 <jakub@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