________________________________
From: David Blaikie <dblai...@gmail.com>
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich <ayerm...@fb.com>
Cc: Richard Biener <richard.guent...@gmail.com>; Jakub Jelinek
<ja...@redhat.com>; Mark Wielaard <m...@klomp.org>; gcc@gcc.gnu.org
<gcc@gcc.gnu.org>; ikud...@accesssoftek.com <ikud...@accesssoftek.com>;
mask...@google.com <mask...@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion
On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich
<ayerm...@fb.com<mailto:ayerm...@fb.com>> wrote:
________________________________
From: David Blaikie <dblai...@gmail.com<mailto:dblai...@gmail.com>>
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>>
Cc: Richard Biener
<richard.guent...@gmail.com<mailto:richard.guent...@gmail.com>>; Jakub Jelinek
<ja...@redhat.com<mailto:ja...@redhat.com>>; Mark Wielaard
<m...@klomp.org<mailto:m...@klomp.org>>;
gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>
<gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>;
ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com>
<ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com>>;
mask...@google.com<mailto:mask...@google.com>
<mask...@google.com<mailto:mask...@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion
On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich
<ayerm...@fb.com<mailto:ayerm...@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)
[Alex] That is a good point, but I guess broader question is if precedence is
not good, should we follow it? If it's clearly documented, might be OK. As my
professor Brian Harvey said many, many, many moons ago during my undergrad:
"RTFM". If my understanding of exchange on this thread is correct, there
doesn't seem to be a consensus on this point.
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.
[Alex] Yep, exactly.
Basically, I am arguing for case of -gdwarf32/64 not enabling -g.
- Dave
Thank You
Alex
________________________________
From: David Blaikie <dblai...@gmail.com<mailto:dblai...@gmail.com>>
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener
<richard.guent...@gmail.com<mailto:richard.guent...@gmail.com>>
Cc: Jakub Jelinek <ja...@redhat.com<mailto:ja...@redhat.com>>; Mark Wielaard
<m...@klomp.org<mailto:m...@klomp.org>>;
gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>
<gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>;
ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com>
<ikud...@accesssoftek.com<mailto:ikud...@accesssoftek.com>>; Alexander
Yermolovich <ayerm...@fb.com<mailto:ayerm...@fb.com>>;
mask...@google.com<mailto:mask...@google.com>
<mask...@google.com<mailto: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<mailto:richard.guent...@gmail.com>> wrote:
>
> On Tue, Nov 24, 2020 at 7:38 PM David Blaikie
> <dblai...@gmail.com<mailto:dblai...@gmail.com>> wrote:
> >
> > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek
> > <ja...@redhat.com<mailto: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<mailto: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
