Re: DWARF64 gcc/clang flag discussion

[David Blaikie <dblaikie@gmail.com>]

On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com>
wrote:

>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@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)




>
>
> 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.
>
>
> Not quite sure I'm following here - if -gdwarf64 does enable -g by default
> it might be quite confusing in such a big complicated build system - where
> a user actually wanted -gmlt or -g0 or some certain library or file, but it
> got overriden by -gdwarf64. (or the inverse - does -gdwarf64 -g mean
> DWARF32 again because that's the default? That's probably not what people
> want most of the time (but sometimes they might want to opt back into
> DWARF32 later in the command line)
>
> [Alex] Primarily from the debug level perspective. If user specifies -g0
> or -gmlt, and -gdwarf64 (assuming it enables -g), then depending on the
> order in command line where build system has put things user might end up
> with level of debug information they wanted, or with default -g.
>

Ah, you mean in the case where -gdwarf64 is debug-info-enabling, then "-g0
-gdwarf64" and "-gdwarf64 -g0" would have different semantics, but if we
make -gdwarf64 a qualifier then those two scenarios won't have different
semantics (both will be -g0) and that would be a good thing for users?
Yeah, I'm with you there.


> Basically, I am arguing for case of -gdwarf32/64 not enabling -g.
>
> - Dave
>
>
>
> 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
>
>