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.