Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU Tools Track (& your thread on on the gdb list about debug_names). Wondering if you (or anyone else you know who's contributing to debug info in GCC) have some thoughts on this flag naming issue. It'd be great to get some alignment between GCC and Clang here, so as we both add new flags going forward, at least they're at least categorically consistent for users, even if we aren't necessarily implementing the exact same flags/flag names (though in the -gsplit-dwarf case, it'd be good for any new semantics/name to match exactly).
On Wed, Jul 29, 2020 at 9:46 AM David Blaikie <dblai...@gmail.com> wrote: > 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 >
