[PATCH] D80391: [Driver] Don't make -gsplit-dwarf imply -g2

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80391