Re: Future debug options: -f* or -g*?
On Wed, Sep 2, 2020 at 4:12 AM Mark Wielaard 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 -fs not imply -g and having > any of the -gs 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 fr
Re: Future debug options: -f* or -g*?
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 -fs not imply -g and having any of the -gs 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*?
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 wrote: > On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell 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
Re: Future debug options: -f* or -g*?
On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell 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
Re: Future debug options: -f* or -g*?
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*?
On Thu, Jul 9, 2020 at 12:03 PM 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)
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 + 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 present
Re: Future debug options: -f* or -g*?
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.
Future debug options: -f* or -g*?
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.
