DWARF64 gcc/clang flag discussion

Richard Biener richard.guenther@gmail.com
Wed Nov 25 09:22:33 GMT 2020

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.
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.).  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:


all others do not.  And yes, the -gsplit-dwarf change went in.


> - Dave

More information about the Gcc mailing list