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

[David Blaikie <dblaikie@gmail.com>]

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.