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

[Fangrui Song]

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.