[PATCH] D59923: [Driver] Simplify -g level computation and its interaction with -gsplit-dwarf

Thu Mar 28 19:46:10 PDT 2019

MaskRay marked an inline comment as done.
MaskRay added a comment.

In D59923#1446508 <https://reviews.llvm.org/D59923#1446508>, @dblaikie wrote:

> What's the general motivation for this work/changes?

The current -gsplit-dwarf handling is a bit complex and the motivation is to make it less confused.

  -g0 -gsplit-dwarf => 2
  -gmlt -gsplit-dwarf -fsplit-dwarf-inlining => 2
  -gmlt -gsplit-dwarf -fno-split-dwarf-inlining => 1 (before) 2 (after)

It is confusing because the composition of `-gmlt -gsplit-dwarf` is different from `-g0 -gsplit-dwarf` when `SplitDWARFInlining` is false.

>> -gmlt -gsplit-dwarf -fno-split-dwarf-inlining => special: 1 (before) 2 (after)
> 
> This ^ is the only semantic change due to this refactoring?

This is the only semantic change.

> There's a desire to be able to compose gmlt+gsplit-dwarf, /if/ -fno-split-dwarf-inlining is enabled. (for context, -fno-split-dwarf-inlining is the default in Google's optimized builds, since split-dwarf-inlining was never implemented in GCC & we didn't want to regress object size when switching from GCC to Clang (& no one had complained about that missing functionality))
> 
> So with -fno-split-dwarf-inlining, there's value in using gmlt with gsplit-dwarf (it reduces the size of the .dwo files - reducing the inputs/size of dwp, etc).
> 
> & it sounds like this change breaks that scenario?

Acknowledged the desire to compose `-gsplit-dwarf -gmlt -fno-split-dwarf-inlining`. After this patch, users should place `-gmplt` after `-gsplit-dwarf`.

In Bazel, the order of the command line options from left to right: feature flags < BUILD `copts=` < `--copt=`. So for targets specifying `-g0`/`-gmlt` in their `copts` / explict `--copts=` options, they will override `-gsplit-dwarf` added by the debug feature.

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59923/new/

https://reviews.llvm.org/D59923