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

[Nathan Sidwell]

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 :)

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