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