On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell <nat...@acm.org> wrote: > > 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 :)
Appreciate the perspective, for sure! It sounds like some folks who've worked on this a fair bit (at least myself, Eric Christopher, and Cary Coutant) have had a different perspective for quite a while - that -g flags generally turn on debug info emission (& customize it in some way, potentially) and -f flags modify the emission but don't enable it. Specifically this conversation arose around changing the semantics of -gsplit-dwarf, which currently enables debug info emission and customizes the nature of that emission. There's a desire to separate these semantics. I have a few issues with this that I'd like to avoid: 1) changing the semantics of an existing flag (I think it's best to introduce a new one, perhaps deprecate the old one), especially across two compilers, issues around version compatibility, etc seem less than ideal 2) especially given the existing semantics of the flag it seems like it'd add to the confusion to make -gsplit-dwarf no longer imply -g2, whereas adding -fsplit-dwarf would be less ambiguous/more clear that this is not going to turn on debug info emission Going forward for new flags, I still feel like (given the current proliferation of -g flags that do enable debug info emission and tweak it) the ambiguity of -g flags is problematic from a usability perspective, but I'd be less opposed to new flags using -g than I am to changing the semantics of an existing -g flag. If GCC is outright "hard no" on -fsplit-dwarf and (sounds like) has already changed -gsplit-dwarf semantics, Clang will essentially have to follow to avoid greater confusion, but I'd like to avoid that if possible. Thoughts? Are there other ways we could reduce the ambiguity between "enables debug info" and "tweaks debug info emission, if enabled"? - Dave > > 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
