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

[David Blaikie <dblaikie@gmail.com>]

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