Fix email addresses:)
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.
