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

[Fangrui Song]

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.