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

[Mark Wielaard <mark@klomp.org>]

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