Future debug options: -f* or -g*?

Future debug options: -f* or -g*?

[Fangrui Song]

Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.

A non-complete list of GCC supported debug options is documented here at
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

I think there options belong to 3 categories:

(a) -f* & doesn't imply -g2: -fdebug-types-section -feliminate-unused-debug-types,
    -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5 implies -g2 & there is need to not imply -g2)
(b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c) http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
                         -gdwarf-5, -ggdb, -gstabs
(c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, -gstrict-dwarf, -gz, ...
             the list appears to be much longer than (b)

( (b) isn't very good to its non-orthogonality. The interaction with -g0 -g1
   and -g3 can be non-obvious sometimes.)

Cary Coutant kindly shared with me his understanding about debug
options (attached at the end). Many established options can't probably
be fixed now. Some are still fixable (-gsplit-dwarf).

This post is mainly about future debug options. Shall we figure out a
convention for future debug options?

Personally I'd prefer (c) but I won't object to (a).
I'd avoid (b).

> In retrospect, I regret not naming the option -fsplit-dwarf, which
> clearly would not have implied -g, and would have fit in with a few
> other dwarf-related -f options. (I don't know whether Richard's
> objection to it is because there is already -gsplit-dwarf, or if he
> would have objected to it as an alternative-universe spelling.)
> 
> At the time, I thought it was fairly common for all/most -g options
> (except -g0) to imply -g. Perhaps that wasn't true then or is no
> longer true now. If the rest of the community is OK with changing
> -gsplit-dwarf to not imply -g, and no one has said it would cause them
> any hardship, I'm OK with your proposed change.
> 
> I did design it so that you could get the equivalent by simply writing
> "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
> environment variable), so that a subsequent -g would not only turn on
> debug but would also enable split-dwarf. We used that fairly regularly
> at Google.
> 
> Regarding how the build system can discover whether or not split dwarf
> is in effect, without parsing all the options presented to gcc, and
> without looking for the side effects (the .dwo files), we dodged that
> in the Google build system by having a higher-level build flag,
> --fission, which would tell the build system to pass -gsplit-dwarf to
> gcc AND look for the .dwo files produced on the side. We simply
> disallowed having the user pass -gsplit-dwarf directly to the
> compiler.
> 
> Feel free to share this.

Re: Future debug options: -f* or -g*?

[Fangrui Song]

Fix email addresses:)

On 2020-07-09, Fangrui Song wrote:
>Both GCC and Clang have implemented many debugging options under -f and
>-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
>
>A non-complete list of GCC supported debug options is documented here at
>https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>
>I think there options belong to 3 categories:
>
>(a) -f* & doesn't imply -g2: -fdebug-types-section -feliminate-unused-debug-types,
>   -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5 implies -g2 & there is need to not imply -g2)
>(b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c) http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
>                        -gdwarf-5, -ggdb, -gstabs
>(c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, -gstrict-dwarf, -gz, ...
>            the list appears to be much longer than (b)
>
>( (b) isn't very good to its non-orthogonality. The interaction with -g0 -g1
>  and -g3 can be non-obvious sometimes.)
>
>Cary Coutant kindly shared with me his understanding about debug
>options (attached at the end). Many established options can't probably
>be fixed now. Some are still fixable (-gsplit-dwarf).
>
>This post is mainly about future debug options. Shall we figure out a
>convention for future debug options?
>
>Personally I'd prefer (c) but I won't object to (a).
>I'd avoid (b).
>
>>In retrospect, I regret not naming the option -fsplit-dwarf, which
>>clearly would not have implied -g, and would have fit in with a few
>>other dwarf-related -f options. (I don't know whether Richard's
>>objection to it is because there is already -gsplit-dwarf, or if he
>>would have objected to it as an alternative-universe spelling.)
>>
>>At the time, I thought it was fairly common for all/most -g options
>>(except -g0) to imply -g. Perhaps that wasn't true then or is no
>>longer true now. If the rest of the community is OK with changing
>>-gsplit-dwarf to not imply -g, and no one has said it would cause them
>>any hardship, I'm OK with your proposed change.
>>
>>I did design it so that you could get the equivalent by simply writing
>>"-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
>>environment variable), so that a subsequent -g would not only turn on
>>debug but would also enable split-dwarf. We used that fairly regularly
>>at Google.
>>
>>Regarding how the build system can discover whether or not split dwarf
>>is in effect, without parsing all the options presented to gcc, and
>>without looking for the side effects (the .dwo files), we dodged that
>>in the Google build system by having a higher-level build flag,
>>--fission, which would tell the build system to pass -gsplit-dwarf to
>>gcc AND look for the .dwo files produced on the side. We simply
>>disallowed having the user pass -gsplit-dwarf directly to the
>>compiler.
>>
>>Feel free to share this.

Re: Future debug options: -f* or -g*?

[David Blaikie]

On Thu, Jul 9, 2020 at 12:03 PM Fangrui Song <maskray@google.com> wrote:
>
> Both GCC and Clang have implemented many debugging options under -f and
> -g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
>
> A non-complete list of GCC supported debug options is documented here at
> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>
> I think there options belong to 3 categories:
>
> (a) -f* & doesn't imply -g2: -fdebug-types-section -feliminate-unused-debug-types,
>     -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5 implies -g2 & there is need to not imply -g2)
> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c) http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
>                          -gdwarf-5, -ggdb, -gstabs
> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, -gstrict-dwarf, -gz, ...
>              the list appears to be much longer than (b)

Not sure that's the case - it seemed about even last I counted. Here's
my count (I didn't test all the -g flags, some might actually be (b)
when I classified them as (c) - which is sort of my
point/preference/issue here: a -f flag I know won't enable debug info,
a -g flag... I'm not entirely sure), going from the Debugging-Options
document:

a)
-fno-eliminate-unused-debug-symbols
-femit-class-debug-always
-fno-merge-debug-strings
-fdebug-prefix-map=old=new
-fvar-tracking
-fvar-tracking-assignments
-fdebug-types-section
-femit-struct-debug-baseonly
-femit-struct-debug-reduced
-femit-struct-debug-detailed
-fno-dwarf2-cfi-asm
-fno-eliminate-unused-debug-types

b)
-g
-ggdb
-gdwarf-N
-gstabs/-gstabs+
-gxcoff/-gxcoff+
-gvms
-g{,gdb,stabs,xcoff,vms}N
-gsplit-dwarf

c)
-gdescribe-dies
-gpubnames
-ggnu-pubnames
-g[no-]record-gcc-switches
-g[no-]strict-dwarf
-g[no-]as-loc-support
-g[no-]as-locview-support
-g[no-]column-info
-g[no-]statement-frontiers
-g[no-]variable-location-views
-g[no-]internal-reset-location-views
-g[no-]inline-points
-gz

And the counts vary a bit depending on how much you collapse variants
(especially in (b), with the format x N combinatorial situation).

The other dimension that'd be harder to get data on, would be how
often each of these flags are used - most of the finer grained
location/variable stuff I doubt people use all that often? The ones
I've used regularly are -gdwarf-N, -ggnu-pubnames,
-fdebug-types-section, that might be about it? So in my case I guess
it's a somewhat even split, but I've learnt that -ggnu-pubnames "isn't
like -g"/doesn't enable production of debug info.

> ( (b) isn't very good to its non-orthogonality. The interaction with -g0 -g1
>    and -g3 can be non-obvious sometimes.)
>
> Cary Coutant kindly shared with me his understanding about debug
> options (attached at the end). Many established options can't probably
> be fixed now. Some are still fixable (-gsplit-dwarf).
>
> This post is mainly about future debug options. Shall we figure out a
> convention for future debug options?
>
> Personally I'd prefer (c) but I won't object to (a).
> I'd avoid (b).

While I have some apprehension about -gsplit-dwarf moving out of (b),
in general (even in -gsplit-dwarf) the orthogonality of "how to emit
DWARF" versus "whether to emit DWARF" is certainly beneficial, and I'm
on board with a general preference/move away from (b) maybe entirely
except for the singular "-g" if we were designing things from scratch.
(that way anyone can set a build policy of "this is the sort of debug
info I need across the project" and "these are the files I need that
debug info for" (by adding -g on a per-file basis), yeah, sometimes
you might want "But on this file I want this kind of debug info
(current -gmlt, for instance)" but you can get that by composition
with -g + <non-debug-enabling-but-debug-affecting> flag, whereas it's
harder or not possible to do the reverse)

> > In retrospect, I regret not naming the option -fsplit-dwarf, which
> > clearly would not have implied -g, and would have fit in with a few
> > other dwarf-related -f options. (I don't know whether Richard's
> > objection to it is because there is already -gsplit-dwarf, or if he
> > would have objected to it as an alternative-universe spelling.)
> >
> > At the time, I thought it was fairly common for all/most -g options
> > (except -g0) to imply -g. Perhaps that wasn't true then or is no
> > longer true now. If the rest of the community is OK with changing
> > -gsplit-dwarf to not imply -g, and no one has said it would cause them
> > any hardship, I'm OK with your proposed change.
> >
> > I did design it so that you could get the equivalent by simply writing
> > "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
> > environment variable), so that a subsequent -g would not only turn on
> > debug but would also enable split-dwarf. We used that fairly regularly
> > at Google.
> >
> > Regarding how the build system can discover whether or not split dwarf
> > is in effect, without parsing all the options presented to gcc, and
> > without looking for the side effects (the .dwo files), we dodged that
> > in the Google build system by having a higher-level build flag,
> > --fission, which would tell the build system to pass -gsplit-dwarf to
> > gcc AND look for the .dwo files produced on the side. We simply
> > disallowed having the user pass -gsplit-dwarf directly to the
> > compiler.
> >
> > Feel free to share this.

Re: Future debug options: -f* or -g*?

[Nathan Sidwell]

On 7/9/20 3:28 PM, Fangrui Song via Gcc wrote:
> Fix email addresses:)
> 

IMHO the -f ones are misnamed.
-fFOO -> affect generated code (non-target-specific) or language feature
-gFOO -> affect debug info
-mFOO -> machine-specific option

the -fdump options are misnamed btw, I remember Jeff Law pointed that out after 
Mark Mitchell added the first one.  I'm not sure why we didn't rename it right 
then.  I'll bet there are other -foptions that don;t match my comfortable world 
view :)

nathan

> On 2020-07-09, Fangrui Song wrote:
>> Both GCC and Clang have implemented many debugging options under -f and
>> -g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
>>
>> A non-complete list of GCC supported debug options is documented here at
>> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>>
>> I think there options belong to 3 categories:
>>
>> (a) -f* & doesn't imply -g2: -fdebug-types-section 
>> -feliminate-unused-debug-types,
>>   -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5 
>> implies -g2 & there is need to not imply -g2)
>> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c) 
>> http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
>>                        -gdwarf-5, -ggdb, -gstabs
>> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, -gstrict-dwarf, 
>> -gz, ...
>>            the list appears to be much longer than (b)
>>
>> ( (b) isn't very good to its non-orthogonality. The interaction with -g0 -g1
>>  and -g3 can be non-obvious sometimes.)
>>
>> Cary Coutant kindly shared with me his understanding about debug
>> options (attached at the end). Many established options can't probably
>> be fixed now. Some are still fixable (-gsplit-dwarf).
>>
>> This post is mainly about future debug options. Shall we figure out a
>> convention for future debug options?
>>
>> Personally I'd prefer (c) but I won't object to (a).
>> I'd avoid (b).
>>
>>> In retrospect, I regret not naming the option -fsplit-dwarf, which
>>> clearly would not have implied -g, and would have fit in with a few
>>> other dwarf-related -f options. (I don't know whether Richard's
>>> objection to it is because there is already -gsplit-dwarf, or if he
>>> would have objected to it as an alternative-universe spelling.)
>>>
>>> At the time, I thought it was fairly common for all/most -g options
>>> (except -g0) to imply -g. Perhaps that wasn't true then or is no
>>> longer true now. If the rest of the community is OK with changing
>>> -gsplit-dwarf to not imply -g, and no one has said it would cause them
>>> any hardship, I'm OK with your proposed change.
>>>
>>> I did design it so that you could get the equivalent by simply writing
>>> "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
>>> environment variable), so that a subsequent -g would not only turn on
>>> debug but would also enable split-dwarf. We used that fairly regularly
>>> at Google.
>>>
>>> Regarding how the build system can discover whether or not split dwarf
>>> is in effect, without parsing all the options presented to gcc, and
>>> without looking for the side effects (the .dwo files), we dodged that
>>> in the Google build system by having a higher-level build flag,
>>> --fission, which would tell the build system to pass -gsplit-dwarf to
>>> gcc AND look for the .dwo files produced on the side. We simply
>>> disallowed having the user pass -gsplit-dwarf directly to the
>>> compiler.
>>>
>>> Feel free to share this.


-- 
Nathan Sidwell

Re: Future debug options: -f* or -g*?

[David Blaikie]

On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell <nathan@acm.org> wrote:
>
> On 7/9/20 3:28 PM, Fangrui Song via Gcc wrote:
> > Fix email addresses:)
> >
>
> IMHO the -f ones are misnamed.
> -fFOO -> affect generated code (non-target-specific) or language feature
> -gFOO -> affect debug info
> -mFOO -> machine-specific option
>
> the -fdump options are misnamed btw, I remember Jeff Law pointed that out after
> Mark Mitchell added the first one.  I'm not sure why we didn't rename it right
> then.  I'll bet there are other -foptions that don;t match my comfortable world
> view :)

Appreciate the perspective, for sure!

It sounds like some folks who've worked on this a fair bit (at least
myself, Eric Christopher, and Cary Coutant) have had a different
perspective for quite a while - that -g flags generally turn on debug
info emission (& customize it in some way, potentially) and -f flags
modify the emission but don't enable it.

Specifically this conversation arose around changing the semantics of
-gsplit-dwarf, which currently enables debug info emission and
customizes the nature of that emission. There's a desire to separate
these semantics.

I have a few issues with this that I'd like to avoid:

1) changing the semantics of an existing flag (I think it's best to
introduce a new one, perhaps deprecate the old one), especially across
two compilers, issues around version compatibility, etc seem less than
ideal
2) especially given the existing semantics of the flag it seems like
it'd add to the confusion to make -gsplit-dwarf no longer imply -g2,
whereas adding -fsplit-dwarf would be less ambiguous/more clear that
this is not going to turn on debug info emission

Going forward for new flags, I still feel like (given the current
proliferation of -g flags that do enable debug info emission and tweak
it) the ambiguity of -g flags is problematic from a usability
perspective, but I'd be less opposed to new flags using -g than I am
to changing the semantics of an existing -g flag.

If GCC is outright "hard no" on -fsplit-dwarf and (sounds like) has
already changed -gsplit-dwarf semantics, Clang will essentially have
to follow to avoid greater confusion, but I'd like to avoid that if
possible.

Thoughts? Are there other ways we could reduce the ambiguity between
"enables debug info" and "tweaks debug info emission, if enabled"?

- Dave

>
> nathan
>
> > On 2020-07-09, Fangrui Song wrote:
> >> Both GCC and Clang have implemented many debugging options under -f and
> >> -g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
> >>
> >> A non-complete list of GCC supported debug options is documented here at
> >> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> >>
> >> I think there options belong to 3 categories:
> >>
> >> (a) -f* & doesn't imply -g2: -fdebug-types-section
> >> -feliminate-unused-debug-types,
> >>   -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5
> >> implies -g2 & there is need to not imply -g2)
> >> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c)
> >> http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
> >>                        -gdwarf-5, -ggdb, -gstabs
> >> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, -gstrict-dwarf,
> >> -gz, ...
> >>            the list appears to be much longer than (b)
> >>
> >> ( (b) isn't very good to its non-orthogonality. The interaction with -g0 -g1
> >>  and -g3 can be non-obvious sometimes.)
> >>
> >> Cary Coutant kindly shared with me his understanding about debug
> >> options (attached at the end). Many established options can't probably
> >> be fixed now. Some are still fixable (-gsplit-dwarf).
> >>
> >> This post is mainly about future debug options. Shall we figure out a
> >> convention for future debug options?
> >>
> >> Personally I'd prefer (c) but I won't object to (a).
> >> I'd avoid (b).
> >>
> >>> In retrospect, I regret not naming the option -fsplit-dwarf, which
> >>> clearly would not have implied -g, and would have fit in with a few
> >>> other dwarf-related -f options. (I don't know whether Richard's
> >>> objection to it is because there is already -gsplit-dwarf, or if he
> >>> would have objected to it as an alternative-universe spelling.)
> >>>
> >>> At the time, I thought it was fairly common for all/most -g options
> >>> (except -g0) to imply -g. Perhaps that wasn't true then or is no
> >>> longer true now. If the rest of the community is OK with changing
> >>> -gsplit-dwarf to not imply -g, and no one has said it would cause them
> >>> any hardship, I'm OK with your proposed change.
> >>>
> >>> I did design it so that you could get the equivalent by simply writing
> >>> "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
> >>> environment variable), so that a subsequent -g would not only turn on
> >>> debug but would also enable split-dwarf. We used that fairly regularly
> >>> at Google.
> >>>
> >>> Regarding how the build system can discover whether or not split dwarf
> >>> is in effect, without parsing all the options presented to gcc, and
> >>> without looking for the side effects (the .dwo files), we dodged that
> >>> in the Google build system by having a higher-level build flag,
> >>> --fission, which would tell the build system to pass -gsplit-dwarf to
> >>> gcc AND look for the .dwo files produced on the side. We simply
> >>> disallowed having the user pass -gsplit-dwarf directly to the
> >>> compiler.
> >>>
> >>> Feel free to share this.
>
>
> --
> Nathan Sidwell

Re: Future debug options: -f* or -g*?

[David Blaikie]

Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU
Tools Track (& your thread on on the gdb list about debug_names). Wondering
if you (or anyone else you know who's contributing to debug info in GCC)
have some thoughts on this flag naming issue. It'd be great to get some
alignment between GCC and Clang here, so as we both add new flags going
forward, at least they're at least categorically consistent for users, even
if we aren't necessarily implementing the exact same flags/flag names
(though in the -gsplit-dwarf case, it'd be good for any new semantics/name
to match exactly).

On Wed, Jul 29, 2020 at 9:46 AM David Blaikie <dblaikie@gmail.com> wrote:

> On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell <nathan@acm.org> wrote:
> >
> > On 7/9/20 3:28 PM, Fangrui Song via Gcc wrote:
> > > Fix email addresses:)
> > >
> >
> > IMHO the -f ones are misnamed.
> > -fFOO -> affect generated code (non-target-specific) or language feature
> > -gFOO -> affect debug info
> > -mFOO -> machine-specific option
> >
> > the -fdump options are misnamed btw, I remember Jeff Law pointed that
> out after
> > Mark Mitchell added the first one.  I'm not sure why we didn't rename it
> right
> > then.  I'll bet there are other -foptions that don;t match my
> comfortable world
> > view :)
>
> Appreciate the perspective, for sure!
>
> It sounds like some folks who've worked on this a fair bit (at least
> myself, Eric Christopher, and Cary Coutant) have had a different
> perspective for quite a while - that -g flags generally turn on debug
> info emission (& customize it in some way, potentially) and -f flags
> modify the emission but don't enable it.
>
> Specifically this conversation arose around changing the semantics of
> -gsplit-dwarf, which currently enables debug info emission and
> customizes the nature of that emission. There's a desire to separate
> these semantics.
>
> I have a few issues with this that I'd like to avoid:
>
> 1) changing the semantics of an existing flag (I think it's best to
> introduce a new one, perhaps deprecate the old one), especially across
> two compilers, issues around version compatibility, etc seem less than
> ideal
> 2) especially given the existing semantics of the flag it seems like
> it'd add to the confusion to make -gsplit-dwarf no longer imply -g2,
> whereas adding -fsplit-dwarf would be less ambiguous/more clear that
> this is not going to turn on debug info emission
>
> Going forward for new flags, I still feel like (given the current
> proliferation of -g flags that do enable debug info emission and tweak
> it) the ambiguity of -g flags is problematic from a usability
> perspective, but I'd be less opposed to new flags using -g than I am
> to changing the semantics of an existing -g flag.
>
> If GCC is outright "hard no" on -fsplit-dwarf and (sounds like) has
> already changed -gsplit-dwarf semantics, Clang will essentially have
> to follow to avoid greater confusion, but I'd like to avoid that if
> possible.
>
> Thoughts? Are there other ways we could reduce the ambiguity between
> "enables debug info" and "tweaks debug info emission, if enabled"?
>
> - Dave
>
> >
> > nathan
> >
> > > On 2020-07-09, Fangrui Song wrote:
> > >> Both GCC and Clang have implemented many debugging options under -f
> and
> > >> -g. Whether options go to -f or -g appears to be pretty arbitrary
> decisions.
> > >>
> > >> A non-complete list of GCC supported debug options is documented here
> at
> > >> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> > >>
> > >> I think there options belong to 3 categories:
> > >>
> > >> (a) -f* & doesn't imply -g2: -fdebug-types-section
> > >> -feliminate-unused-debug-types,
> > >>   -fdebug-default-version=5 (this exists in clang purely because
> -gdwarf-5
> > >> implies -g2 & there is need to not imply -g2)
> > >> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c)
> > >> http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
> > >>                        -gdwarf-5, -ggdb, -gstabs
> > >> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info,
> -gstrict-dwarf,
> > >> -gz, ...
> > >>            the list appears to be much longer than (b)
> > >>
> > >> ( (b) isn't very good to its non-orthogonality. The interaction with
> -g0 -g1
> > >>  and -g3 can be non-obvious sometimes.)
> > >>
> > >> Cary Coutant kindly shared with me his understanding about debug
> > >> options (attached at the end). Many established options can't probably
> > >> be fixed now. Some are still fixable (-gsplit-dwarf).
> > >>
> > >> This post is mainly about future debug options. Shall we figure out a
> > >> convention for future debug options?
> > >>
> > >> Personally I'd prefer (c) but I won't object to (a).
> > >> I'd avoid (b).
> > >>
> > >>> In retrospect, I regret not naming the option -fsplit-dwarf, which
> > >>> clearly would not have implied -g, and would have fit in with a few
> > >>> other dwarf-related -f options. (I don't know whether Richard's
> > >>> objection to it is because there is already -gsplit-dwarf, or if he
> > >>> would have objected to it as an alternative-universe spelling.)
> > >>>
> > >>> At the time, I thought it was fairly common for all/most -g options
> > >>> (except -g0) to imply -g. Perhaps that wasn't true then or is no
> > >>> longer true now. If the rest of the community is OK with changing
> > >>> -gsplit-dwarf to not imply -g, and no one has said it would cause
> them
> > >>> any hardship, I'm OK with your proposed change.
> > >>>
> > >>> I did design it so that you could get the equivalent by simply
> writing
> > >>> "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via
> an
> > >>> environment variable), so that a subsequent -g would not only turn on
> > >>> debug but would also enable split-dwarf. We used that fairly
> regularly
> > >>> at Google.
> > >>>
> > >>> Regarding how the build system can discover whether or not split
> dwarf
> > >>> is in effect, without parsing all the options presented to gcc, and
> > >>> without looking for the side effects (the .dwo files), we dodged that
> > >>> in the Google build system by having a higher-level build flag,
> > >>> --fission, which would tell the build system to pass -gsplit-dwarf to
> > >>> gcc AND look for the .dwo files produced on the side. We simply
> > >>> disallowed having the user pass -gsplit-dwarf directly to the
> > >>> compiler.
> > >>>
> > >>> Feel free to share this.
> >
> >
> > --
> > Nathan Sidwell
>

Re: Future debug options: -f* or -g*?

[Mark Wielaard]

Hi David,

On Mon, 2020-08-31 at 20:10 -0700, David Blaikie wrote:
> Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU
> Tools Track (& your thread on on the gdb list about debug_names). Wondering
> if you (or anyone else you know who's contributing to debug info in GCC)
> have some thoughts on this flag naming issue. It'd be great to get some
> alignment between GCC and Clang here, so as we both add new flags going
> forward, at least they're at least categorically consistent for users, even
> if we aren't necessarily implementing the exact same flags/flag names
> (though in the -gsplit-dwarf case, it'd be good for any new semantics/name
> to match exactly).

To be honest I don't have any deep insights here. Sadly it is just a
bit of a mess. Not helped by the fact that some debugging formats, like
DWARF have a number in their name (dwarf2) that might not reflect
actually reflext the version of that format (except for it being not-
dwarf1). That is why I was suggesting to use -fdwarf(32|64) instead of
-gdwarf(32|64) to use for 32 bits vs 64 bits offsets in dwarf(2|3|4|5),
because there are already too many -gdwarf[number] options.

The idea of having any of the -f<debug-option>s not imply -g and having
any of the -g<debug-option>s imply -g seems a good one.

But in general I think these suboptions are all a bit nonsense though.
They are great for tinkering and playing with corner cases of the
debugging format. But I don't think we are helping real developers with
them. To make any of them useful they should be in one of the standard
options that people actually use. Nobody has time (or the specialized
knowledge) to really care about all these suboptions. Once people feel
they need to use any of these suboptions we already lost or the user
has such specialized knowledge that they will know about specific
changes in these options or between compilers.

So just like we have -Wall or -Wextra has groups of warning options
people are likely to use and we have -O1, -O2 and -O3 (I personally
believe -flto should just be in -O3 instead of being a separate
option), we should simply focus on making -g1, -g2 and -g3 have good
defaults. Where -g1 is the minimum needed to do some
profiling/tracing/debugging without needing to map all addresses back
to source completely but can leave out full type trees for example, -g2
is the default for being able to do a useful interactive debugging
session and -g3 adds some (expensive) extras like .debug_macros and
maybe .debug_names, etc.

With respect to -gsplit-dwarf I think it was (in hindsight) a mistake
to put things in a separate (.dwo) file. It is a bit confusing to users
and complicates build systems immensely. I am hoping to implement
-gsplit-dwarf=single using SHF_EXCLUDED for gcc and then make that the
default.

Cheers,

Mark

Re: Future debug options: -f* or -g*?

[David Blaikie]

On Wed, Sep 2, 2020 at 4:12 AM Mark Wielaard <mark@klomp.org> wrote:

> Hi David,
>
> On Mon, 2020-08-31 at 20:10 -0700, David Blaikie wrote:
> > Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU
> > Tools Track (& your thread on on the gdb list about debug_names).
> Wondering
> > if you (or anyone else you know who's contributing to debug info in GCC)
> > have some thoughts on this flag naming issue. It'd be great to get some
> > alignment between GCC and Clang here, so as we both add new flags going
> > forward, at least they're at least categorically consistent for users,
> even
> > if we aren't necessarily implementing the exact same flags/flag names
> > (though in the -gsplit-dwarf case, it'd be good for any new
> semantics/name
> > to match exactly).
>
> To be honest I don't have any deep insights here. Sadly it is just a
> bit of a mess.


Happen to know any other interested parties (other GCC DWARF contributors
who might have an opinion on flag naming) who might want to weigh in/help
us converge here?


> Not helped by the fact that some debugging formats, like
> DWARF have a number in their name (dwarf2) that might not reflect
> actually reflext the version of that format (except for it being not-
> dwarf1). That is why I was suggesting to use -fdwarf(32|64) instead of
> -gdwarf(32|64) to use for 32 bits vs 64 bits offsets in dwarf(2|3|4|5),
> because there are already too many -gdwarf[number] options.
>
> The idea of having any of the -f<debug-option>s not imply -g and having
> any of the -g<debug-option>s imply -g seems a good one.
>

Cool cool.


> But in general I think these suboptions are all a bit nonsense though.
> They are great for tinkering and playing with corner cases of the
> debugging format. But I don't think we are helping real developers with
> them. To make any of them useful they should be in one of the standard
> options that people actually use. Nobody has time (or the specialized
> knowledge) to really care about all these suboptions. Once people feel
> they need to use any of these suboptions we already lost or the user
> has such specialized knowledge that they will know about specific
> changes in these options or between compilers.
>

Perhaps - I think there are different use cases. A big one in LLVM we call
-fstandalone-debug: Are you building everything with debug info, or only
one or two files/can the compiler assume other files will be built with
debug info. (this affects basically the same things as
-femit-class-debug-always). Split DWARF for users with distributed build
systems. Several options can weight object size compared to linked
executable size - such as using base address selection entries in range and
location lists (reducing relocations). Obviously I'm biased here - I live
in this stuff & have users/use cases that are... not the norm.


> So just like we have -Wall or -Wextra has groups of warning options
> people are likely to use and we have -O1, -O2 and -O3 (I personally
> believe -flto should just be in -O3 instead of being a separate
> option),


I imagine quite a few users build with optimization for particular CPUs -
though, again, partly my bias of working on a homogenous/controlled
environment in data centers, rather than trying to build a binary to send
to random users in the world. But I'd guess games and things that want to
eek out performance probably want to use modern CPU features if available.


> we should simply focus on making -g1, -g2 and -g3 have good
> defaults. Where -g1 is the minimum needed to do some
> profiling/tracing/debugging without needing to map all addresses back
> to source completely but can leave out full type trees for example, -g2
> is the default for being able to do a useful interactive debugging
> session and -g3 adds some (expensive) extras like .debug_macros and
> maybe .debug_names, etc.
>

Maybe. I'd guess a fair few users (especially in their continuous
integration systems, etc) might have some different tradeoffs in terms of
compile/link time and debugging/debugger startup time (indexes are a
particularly potent example of this - pay some link time for some debugger
startup improvement - but if I don't use a debugger very often, I may not
want to pay that link time cost all the time).


> With respect to -gsplit-dwarf I think it was (in hindsight) a mistake
> to put things in a separate (.dwo) file. It is a bit confusing to users
> and complicates build systems immensely. I am hoping to implement
> -gsplit-dwarf=single using SHF_EXCLUDED for gcc and then make that the
> default.
>

Yeah, we've got support for that model in Clang - but to be honest, one of
the major motivations for implementing Split DWARF was Google's internal
use (big distributed build system) & the split mode isn't a mistake in this
context - not having to ship all the DWARF bytes to the machine doing the
link is a significant savings. (even if we ship all those bytes to another
machine to make a dwp) and smaller files to pull down when a user wants to
debug from the dwo files - they pull down the executable, then as-needed,
based on the index, pull down dwo files - if gsplit-dwarf=single was used,
in addition to shipping the dwo bytes to the linker, you also re-ship the
non-dwo bytes for any object file that needs to be pulled over the network
for debugging, rather than only the dwo bytes.

- David