Re: DWARF64 gcc/clang flag discussion

[David Blaikie <dblaikie@gmail.com>]

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)

- Dave