Page MenuHomePhabricator

[Driver] Don't make -gsplit-dwarf imply -g2
Needs ReviewPublic

Authored by MaskRay on May 21 2020, 11:13 AM.

Details

Summary

RFC: http://lists.llvm.org/pipermail/cfe-dev/2020-May/065430.html
Agreement from GCC: https://sourceware.org/pipermail/gcc-patches/2020-May/545688.html

g_flags_Group options generally don't affect the amount of debugging
information. -gsplit-dwarf is an exception. Its order dependency with
other gN_Group options make it inconvenient in a build system:

  • -g0 -gsplit-dwarf -> level 2 -gsplit-dwarf "upgrades" the amount of debugging information despite the previous intention (-g0) to drop debugging information
  • -g1 -gsplit-dwarf -> level 2 -gsplit-dwarf "upgrades" the amount of debugging information.
  • If we have a higher-level -gN, -gN -gsplit-dwarf will supposedly decrease the amount of debugging information. This happens with GCC -g3.

The non-orthogonality has confused many users. This patch fixes the
problem by dropping the -g2 implication of -gsplit-dwarf. New semantics:

  • If there is a g_Group, allow split DWARF. (There are still conditions split DWARF is disabled if it is not beneficial: -g0, -gline-directives-only, -g1 -fno-split-dwarf-inlining)
  • Otherwise, no-op.

To restore the original behavior, replace -gsplit-dwarf with -gsplit-dwarf -g.

Diff Detail

Event Timeline

MaskRay created this revision.May 21 2020, 11:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 21 2020, 11:13 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I think it's probably best to keep this subject on the cfe-dev thread until there's agreement there.

Received Cary's response and I am authorized to share this

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.

My remark here: GCC folks think introducing another -fsplit-dwarf will be more confusing at this point.

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.

My take of "-gsplit-dwarf implies -g" on cfe-dev is that people don't have strong opinions on updated semantics but they do notice that the implied -g2 is confusing.

@dblaikie I think we can proceed with this patch. I'll follow up on GCC side. Clang 11 will be consistent with GCC 11.

Ping...

Was hoping to get some more discussion on the general debug flag naming thread on the GCC list, but that hasn't happened - so I've replied/poked it a bit: https://gcc.gnu.org/pipermail/gcc/2020-July/233282.html (@echristo - sorry, thought you were on that thread, guess you got dropped somewhere along the way (I saw an "Eric" in the reply line and figured it was you) - wouldn't mind if you took a look/weighed in, if you've got anything to share on the topic)