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

[MaskRay]

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. GCC 11 will change the semantics
(-gsplit-dwarf no longer implies -g2) despite the backwards compatibility break.
This patch matches its behavior.

New semantics:

• If there is a g_Group, allow split DWARF if useful: (not one of the following: -g0, -gline-directives-only, -g1 -fno-split-dwarf-inlining)
• Otherwise, no-op.

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

[dblaikie]

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

[MaskRay]

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.

[MaskRay]

Ping...

[dblaikie]

In D80391#2179182, @MaskRay wrote:

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)

[dblaikie]

Looks like GCC has changed the semantics here despite the backwards compatibility break - as much as I'd rather not break backwards compatibility it's probably best on balance to maintain GCC compatibility instead: https://godbolt.org/z/zGanxE

Could you either provide in this patch or a follow-up, a -gno-split-dwarf flag? (probabyl better in a follow-up)

Could you check that this is compatible with the cmake split DWARF support in the LLVM build system, and with Google's internal use, before committing? (not sure there are any other users of this feature we can effectively update - or that I specifically know of)

clang/lib/Driver/ToolChains/Clang.cpp

3718

Rather than undoing the DwarfFission uinitialization, instead could the DwarfFission initialization be rolled into the "if (gN_Group)" condition?

[MaskRay]

In D80391#2437926, @dblaikie wrote:

Looks like GCC has changed the semantics here despite the backwards compatibility break - as much as I'd rather not break backwards compatibility it's probably best on balance to maintain GCC compatibility instead: https://godbolt.org/z/zGanxE

Could you either provide in this patch or a follow-up, a -gno-split-dwarf flag? (probabyl better in a follow-up)

Sounds good. Will add -gno-split-dwarf

Could you check that this is compatible with the cmake split DWARF support in the LLVM build system, and with Google's internal use, before committing? (not sure there are any other users of this feature we can effectively update - or that I specifically know of)

Will do! I can test whether ("-gsplit-dwarf" -> "-gsplit-dwarf -g") exposes any issue. The new -gsplit-dwarf -g should be equivalent to the old -gsplit-dwarf

[dblaikie]

In D80391#2438447, @MaskRay wrote:

In D80391#2437926, @dblaikie wrote:

Looks like GCC has changed the semantics here despite the backwards compatibility break - as much as I'd rather not break backwards compatibility it's probably best on balance to maintain GCC compatibility instead: https://godbolt.org/z/zGanxE

Could you either provide in this patch or a follow-up, a -gno-split-dwarf flag? (probabyl better in a follow-up)

Sounds good. Will add -gno-split-dwarf

Great, thanks!

Could you check that this is compatible with the cmake split DWARF support in the LLVM build system, and with Google's internal use, before committing? (not sure there are any other users of this feature we can effectively update - or that I specifically know of)

Will do! I can test whether ("-gsplit-dwarf" -> "-gsplit-dwarf -g") exposes any issue. The new -gsplit-dwarf should be equivalent to the old -gsplit-dwarf -g

Yeah, likely what would be suitable would be to add the -g to both those use cases before committing the change in behavior.

[MaskRay]

clang/lib/Driver/ToolChains/Clang.cpp

3718

I could add the OPT_g_Group check to getDebugFissionKind, but that would make the effects of -g0 and "no -g at all" into two places. Having the code here makes it closer to "how DebugInfoKind == codegenoptions::NoDebugInfo affects fission" above.

[dblaikie]

clang/lib/Driver/ToolChains/Clang.cpp

3718

Sorry, I'm not following what you're suggesting/discussing. I wasn't meaning to suggest duplicating the OPT_g_Group check.

Code something like:

if (const Arg *A = Args.getLastArg(options::OPT_g_Group)) {
  DebugInfoKind = codegenoptions::LimitedDebugInfo;

  Arg* SplitDWARFArg;
  DwarfFission = getDebugFissionKind(D, Args, SplitDWARFArg);

  if (DwarfFission != DwarfFissionKind::None &&
      !checkDebugInfoOption(SplitDWARFArg, Args, D, TC)) {
    DwarfFission = DwarfFissionKind::None;
    SplitDWARFInlining = false;
  }

  // If the last option explicitly specified a debug-info level, use it.
  if (checkDebugInfoOption(A, Args, D, TC) &&
      A->getOption().matches(options::OPT_gN_Group)) {
    DebugInfoKind = DebugLevelToInfoKind(*A);
    // For -g0 or -gline-tables-only, drop -gsplit-dwarf. This gets a bit more
    // complicated if you've disabled inline info in the skeleton CUs
    // (SplitDWARFInlining) - then there's value in composing split-dwarf and
    // line-tables-only, so let those compose naturally in that case.
    if (DebugInfoKind == codegenoptions::NoDebugInfo ||
        DebugInfoKind == codegenoptions::DebugDirectivesOnly ||
        (DebugInfoKind == codegenoptions::DebugLineTablesOnly &&
         SplitDWARFInlining))
      DwarfFission = DwarfFissionKind::None;
  }
}

This way, hopefully, there wouldn't be a period where DwarfFission is incorrectly set and has to be reverted to "None", making it less likely the incorrect value could be used accidentally

[MaskRay]

Comment

[MaskRay]

In D80391#2438447, @MaskRay wrote:

In D80391#2437926, @dblaikie wrote:

Looks like GCC has changed the semantics here despite the backwards compatibility break - as much as I'd rather not break backwards compatibility it's probably best on balance to maintain GCC compatibility instead: https://godbolt.org/z/zGanxE

Could you either provide in this patch or a follow-up, a -gno-split-dwarf flag? (probabyl better in a follow-up)

Sounds good. Will add -gno-split-dwarf

D92809

Could you check that this is compatible with the cmake split DWARF support in the LLVM build system, and with Google's internal use, before committing? (not sure there are any other users of this feature we can effectively update - or that I specifically know of)

Will do! I can test whether ("-gsplit-dwarf" -> "-gsplit-dwarf -g") exposes any issue. The new -gsplit-dwarf -g should be equivalent to the old -gsplit-dwarf

Performed an internal test -> passed.

For llvm/cmake/modules/HandleLLVMOptions.cmake, LLVM_USE_SPLIT_DWARF only works with DEBUG/RELWITHDEBINFO, so there should be no difference.

[MaskRay]

I have also notified ChromeOS/Android NDK/Bazel maintainers since they use -gsplit-dwarf (though might not be affected).

[thakis]

Do we emit a warning if we see -gsplit-dwarf alone? Should we?

[thakis]

clang/docs/ReleaseNotes.rst

111

This apparently bit us (chromium) in thinlto configs. Could this here be more explicit that -gsplit-dwarf now needs an explicit -g2 in cflags, and if using thinlto, in ldflags as well?

[MaskRay]

In D80391#2496583, @thakis wrote:

Do we emit a warning if we see -gsplit-dwarf alone? Should we?

{gcc,clang} -gcolumn-info -fdebug-types-section -c -Wall a.c does not warn about unused -gcolumn-info. Not having a warning makes such toggle flags more independent. Users can add them as default without checking about -g levels.

This apparently bit us (chromium) in thinlto configs. Could this here be more explicit that -gsplit-dwarf now needs an explicit -g2 in cflags, and if using thinlto, in ldflags as well?

(I CCed you in a message half a year ago. My apologies, I probably should notified you again)

[dblaikie]

clang/docs/ReleaseNotes.rst

111

Arguably I think maybe it should be fixed/made to work for (thin)lto with -g2 in cflags and -gsplit-dwarf in ldflags, without the need to specify -g2 in ldflags (if that's what you're saying is currently required). Since the -gN level would hopefully at best be ignored (because the IR carries the N in -gN with it, and it'd be unfortunate it enabling split dwarf meant you had to ignore all your per-file -gN levels, or that the -gN is ignored except for allowing -gsplit-dwarf to be respected).

@MaskRay ?

[MaskRay]

clang/docs/ReleaseNotes.rst

111

LLD LTO does not have debug related options. ld -g is an ignored compatibility option. LLD somewhat inherited that from GNU ld. I don't think -gsplit-dwarf or -g can be separately controlled in ldflags.

@thakis Can you share the crbug.com discussion thread?

[dblaikie]

clang/docs/ReleaseNotes.rst

111

Hmm, I guess the thing that bit Chromium would've been the need to add -g2 to cflags where previously it might've been just -gsplit-dwarf for cflags and ldflags.

But it doesn't look like -g2 is needed in ldflags, only passing it to the compilation seems sufficient, then the -gsplit-dwarf passed to the link step is respected:

$ clang++-tot -flto=thin test.cpp -g -c && clang++-tot -flto=thin -fuse-ld=lld -gsplit-dwarf test.o && llvm-dwarfdump-tot a.out
a.out:  file format elf64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x0000002c, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000030)

0x0000000b: DW_TAG_compile_unit
              DW_AT_stmt_list   (0x00000000)
              DW_AT_comp_dir    ("/usr/local/google/home/blaikie/dev/scratch")
              DW_AT_GNU_dwo_name        ("a.out_dwo/1.dwo")
              DW_AT_GNU_dwo_id  (0xf29563d7c812deae)
              DW_AT_low_pc      (0x0000000000201730)
              DW_AT_high_pc     (0x0000000000201738)
              DW_AT_GNU_addr_base       (0x00000000)
$ clang++-tot -flto=thin test.cpp -g -c && clang++-tot -flto=thin -fuse-ld=lld  test.o && llvm-dwarfdump-tot a.out
a.out:  file format elf64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000047, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x0000004b)

0x0000000b: DW_TAG_compile_unit
              DW_AT_producer    ("clang version 12.0.0 ([e-mail]:llvm/llvm-project.git 0d88d7d82bc44b211a8187650a06c6cd3492186a)")
              DW_AT_language    (DW_LANG_C_plus_plus_14)
              DW_AT_name        ("test.cpp")
              DW_AT_stmt_list   (0x00000000)
              DW_AT_comp_dir    ("/usr/local/google/home/blaikie/dev/scratch")
              DW_AT_low_pc      (0x0000000000201730)
              DW_AT_high_pc     (0x0000000000201738)

0x0000002a:   DW_TAG_subprogram
                DW_AT_low_pc    (0x0000000000201730)
                DW_AT_high_pc   (0x0000000000201738)
                DW_AT_frame_base        (DW_OP_reg6 RBP)
                DW_AT_name      ("main")
                DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/test.cpp")
                DW_AT_decl_line (3)
                DW_AT_type      (0x00000043 "int")
                DW_AT_external  (true)

0x00000043:   DW_TAG_base_type
                DW_AT_name      ("int")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x04)

0x0000004a:   NULL

[inglorion]

For Chrome on Chrome OS, this is https://crbug.com/1158215

Here, we saw our links fail with "output file too large". Investigation revealed that debug info was being included in the binary, instead of in .dwo files as expected. That turned out to be caused by this change.

It seems that there are cases where -gsplit-dwarf is passed, but it does not take effect because there isn't also a -g (or -g<level>) option:

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf foo.o -o foo.bin.o

Shows no .dwo file and debug info in foo.bin.o, whereas

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf -g foo.o -o foo.bin.o

shows a .dwo file which is referenced from foo.bin.o

The only thing that is different here is that the latter command has "-g" whereas the former doesn't.

In other words, the new implementation still doesn't make -g and -gsplit-dwarf fully orthogonal; instead of -gsplit-dwarf always turning on debug fission, it *only* turns it on when there is also a -g or -g<level> option - at least in distributed ThinLTO code generation.

It seems that orthogonality was the motivation for this change, and that -gsplit-dwarf without -g is supposed to work in the linker (per MaskRay's comment about -g being ignored by the linker).

Can we make it so that -gsplit-dwarf turns on debug fission and we then use that even if no -g options were passed?

[dblaikie]

In D80391#2497018, @inglorion wrote:

For Chrome on Chrome OS, this is https://crbug.com/1158215

Here, we saw our links fail with "output file too large". Investigation revealed that debug info was being included in the binary, instead of in .dwo files as expected. That turned out to be caused by this change.

It seems that there are cases where -gsplit-dwarf is passed, but it does not take effect because there isn't also a -g (or -g<level>) option:

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf foo.o -o foo.bin.o

Shows no .dwo file and debug info in foo.bin.o, whereas

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf -g foo.o -o foo.bin.o

shows a .dwo file which is referenced from foo.bin.o

The only thing that is different here is that the latter command has "-g" whereas the former doesn't.

In other words, the new implementation still doesn't make -g and -gsplit-dwarf fully orthogonal; instead of -gsplit-dwarf always turning on debug fission, it *only* turns it on when there is also a -g or -g<level> option - at least in distributed ThinLTO code generation.

It seems that orthogonality was the motivation for this change, and that -gsplit-dwarf without -g is supposed to work in the linker (per MaskRay's comment about -g being ignored by the linker).

Can we make it so that -gsplit-dwarf turns on debug fission and we then use that even if no -g options were passed?

Ah, sorry - I assumed you were using implicit thinlto rather than explicit thinlto.

Yes, I think you've demonstrated a bug here - hopefully @MaskRay can look into/fix this so that only -gN is required when the IR is generated and only -gsplit-dwarf is required when real object files are generated - without needing both files even when only one of those operations (IR generation or object generation) is being performed.

[MaskRay]

In D80391#2497018, @inglorion wrote:

For Chrome on Chrome OS, this is https://crbug.com/1158215

Here, we saw our links fail with "output file too large". Investigation revealed that debug info was being included in the binary, instead of in .dwo files as expected. That turned out to be caused by this change.

It seems that there are cases where -gsplit-dwarf is passed, but it does not take effect because there isn't also a -g (or -g<level>) option:

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf foo.o -o foo.bin.o

Shows no .dwo file and debug info in foo.bin.o, whereas

clang -c -fthinlto-index=foo.o.thinlto.bc -gsplit-dwarf -g foo.o -o foo.bin.o

shows a .dwo file which is referenced from foo.bin.o

The only thing that is different here is that the latter command has "-g" whereas the former doesn't.

In other words, the new implementation still doesn't make -g and -gsplit-dwarf fully orthogonal; instead of -gsplit-dwarf always turning on debug fission, it *only* turns it on when there is also a -g or -g<level> option - at least in distributed ThinLTO code generation.

It seems that orthogonality was the motivation for this change, and that -gsplit-dwarf without -g is supposed to work in the linker (per MaskRay's comment about -g being ignored by the linker).

Can we make it so that -gsplit-dwarf turns on debug fission and we then use that even if no -g options were passed?

I am still confused what the problem is. I added some comments to the following distributed ThinLTO example.
Both -gsplit-dwarf and -g are needed for the ThinLTO backend compile step (-fthinlto-index=):

cat > ./a.c <<eof
int foo();
int main() { return foo();}
eof
echo 'int foo() {return 42; }' > ./b.c
cat > ./Makefile <<eof
clang := /tmp/RelA/bin/clang
all: final_link

compile a.o b.o a.indexing.o b.indexing.o: a.c b.c
# -gsplit-dwarf in the initial compile is a no-op.
        $(clang) -gsplit-dwarf -g -O2 -c -flto=thin -fthin-link-bitcode=a.indexing.o a.c
        $(clang) -gsplit-dwarf -g -O2 -c -flto=thin -fthin-link-bitcode=b.indexing.o b.c

thin_link lto/a.o.thinlto.bc lto/b.o.thinlto.bc a.rsp: a.indexing.o b.indexing.o
        $(clang) -fuse-ld=lld -Wl,--thinlto-index-only=a.rsp -Wl,--thinlto-prefix-replace=';lto/' -Wl,--thinlto-object-suffix-replace='.indexing.o;.o' a.indexing.o b.indexing.o

thinlto_backend lto/a.o lto/b.o: a.o b.o lto/a.o.thinlto.bc lto/b.o.thinlto.bc
# This does not produce lto/a.dwo
# Both -gsplit-dwarf and -g are needed to get lto/a.dwo
        $(clang) -g -O2 -c -fthinlto-index=lto/a.o.thinlto.bc a.o -o lto/a.o
        $(clang) -g -O2 -c -fthinlto-index=lto/b.o.thinlto.bc b.o -o lto/b.o

final_link exe: lto/a.o lto/b.o a.rsp
        $(clang) -fuse-ld=lld @a.rsp -o exe

clean:
        $(RM) -f *.o lto/*.o lto/*.bc lto/*.dwo
eof
mkdir -p ./lto

[MaskRay]

From @dblaikie's email reply:

^ this I would consider to be a bug. -g should be needed to generate debug info into the IR, and -gsplit-dwarf should be needed to choose how debug info already in the IR should be placed into object files or dwo files.

Usually (non-LTO) these two steps are in the same compile, so -g and -gsplit-dwarf go together. But for LTO cases, I think it's suitable for -g to be needed for IR generation, and -gsplit-dwarf to be needed for object code generation, without needing -g as well in that latter step (the -g was already specified at IR generation time, and that shoul be enough).

We can see that behavior I'm describing as desirable in implicit ThinLTO I showed earlier in the thread.

I suggest this should be the desired behavior, because -g generally has no effect on IR->object code generation, so it seems strange/unnecessary to me to gate -gsplit-dwarf behind -g in that case. The -g was already specified and used during IR generation (& the -gN level, -gmlt behavior-etc has all been handled in IR generation (or embedded in the IR for use later) - so to me, specifying -g again during object code generation would be/is strange, because any special values would be ignored (-g1/g2/g3/etc would not be respected - the N value would only be respected when passed to the IR generation step))

Got it. -fthinlto-index= (thinlto backend compile) operates on bitcode files and does not IR generation. It isn't suitable for -g to be needed to use.
-gsplit-dwarf is both an IR generation option and an object file generation option. It is needed for thinlto backend compiles.

In Bazel, I think a typical configuration's LTO Backend Compile includes almost every option in the initial compile, so I did not notice the issue. I am working on a patch.

[dblaikie]

In D80391#2497073, @MaskRay wrote:

From @dblaikie's email reply:

^ this I would consider to be a bug. -g should be needed to generate debug info into the IR, and -gsplit-dwarf should be needed to choose how debug info already in the IR should be placed into object files or dwo files.

Usually (non-LTO) these two steps are in the same compile, so -g and -gsplit-dwarf go together. But for LTO cases, I think it's suitable for -g to be needed for IR generation, and -gsplit-dwarf to be needed for object code generation, without needing -g as well in that latter step (the -g was already specified at IR generation time, and that shoul be enough).

We can see that behavior I'm describing as desirable in implicit ThinLTO I showed earlier in the thread.

I suggest this should be the desired behavior, because -g generally has no effect on IR->object code generation, so it seems strange/unnecessary to me to gate -gsplit-dwarf behind -g in that case. The -g was already specified and used during IR generation (& the -gN level, -gmlt behavior-etc has all been handled in IR generation (or embedded in the IR for use later) - so to me, specifying -g again during object code generation would be/is strange, because any special values would be ignored (-g1/g2/g3/etc would not be respected - the N value would only be respected when passed to the IR generation step))

Got it. -fthinlto-index= (thinlto backend compile) operates on bitcode files and does not IR generation. It isn't suitable for -g to be needed to use.
-gsplit-dwarf is both an IR generation option and an object file generation option. It is needed for thinlto backend compiles.

(sounds like we're mostly on the same page now - minor note though: I don't think -gsplit-dwarf is an IR generation option. I don't think it has any effect on IR generation - I believe the IR is exactly the same whether it ends up being used with split or unsplit DWARF generation)

In Bazel, I think a typical configuration's LTO Backend Compile includes almost every option in the initial compile, so I did not notice the issue. I am working on a patch.

Thanks!

clang/docs/ReleaseNotes.rst

 future versions of Clang.
 
 - ...
 
 Modified Compiler Flags
 -----------------------
 
 - -fno-common has been enabled as the default for all targets.  Therefore, C
   code that uses tentative definitions as definitions of a variable in multiple
   translation units will trigger multiple-definition linker errors. Generally,
   this occurs when the use of the ``extern`` keyword is neglected in the
   declaration of a variable in a header file. In some cases, no specific
   translation unit provides a definition of the variable. The previous
   behavior can be restored by specifying ``-fcommon``.
 - -Wasm-ignored-qualifier (ex. `asm const ("")`) has been removed and replaced
   with an error (this matches a recent change in GCC-9).
 - -Wasm-file-asm-volatile (ex. `asm volatile ("")` at global scope) has been
   removed and replaced with an error (this matches GCC's behavior).
 - Duplicate qualifiers on asm statements (ex. `asm volatile volatile ("")`) no
   longer produces a warning via -Wduplicate-decl-specifier, but now an error
   (this matches GCC's behavior).
 - The deprecated argument ``-f[no-]sanitize-recover`` has changed to mean
   ``-f[no-]sanitize-recover=all`` instead of
   ``-f[no-]sanitize-recover=undefined,integer`` and is no longer deprecated.
 - The argument to ``-f[no-]sanitize-trap=...`` is now optional and defaults to
   ``all``.
 - ``-fno-char8_t`` now disables the ``char8_t`` keyword, not just the use of
   ``char8_t`` as the character type of ``u8`` literals. This restores the
   Clang 8 behavior that regressed in Clang 9 and 10.
 - -print-targets has been added to print the registered targets.
+- ``-gsplit-dwarf`` no longer implies ``-g2``.
 
 New Pragmas in Clang
 --------------------
 
 - ...
 
 Attribute Changes in Clang
 --------------------------

clang/lib/Driver/ToolChains/Clang.cpp

static void RenderDebugOptions(const ToolChain &TC, const Driver &D,
   DwarfFission = getDebugFissionKind(D, Args, SplitDWARFArg);
 
   if (DwarfFission != DwarfFissionKind::None &&
       !checkDebugInfoOption(SplitDWARFArg, Args, D, TC)) {
     DwarfFission = DwarfFissionKind::None;
     SplitDWARFInlining = false;
   }
 
-  if (const Arg *A =
-          Args.getLastArg(options::OPT_g_Group, options::OPT_gsplit_dwarf,
-                          options::OPT_gsplit_dwarf_EQ)) {
+  if (const Arg *A = Args.getLastArg(options::OPT_g_Group)) {
     DebugInfoKind = codegenoptions::LimitedDebugInfo;
 
     // If the last option explicitly specified a debug-info level, use it.
     if (checkDebugInfoOption(A, Args, D, TC) &&
         A->getOption().matches(options::OPT_gN_Group)) {
       DebugInfoKind = DebugLevelToInfoKind(*A);
       // For -g0 or -gline-tables-only, drop -gsplit-dwarf. This gets a bit more
       // complicated if you've disabled inline info in the skeleton CUs
       // (SplitDWARFInlining) - then there's value in composing split-dwarf and
       // line-tables-only, so let those compose naturally in that case.
       if (DebugInfoKind == codegenoptions::NoDebugInfo ||
           DebugInfoKind == codegenoptions::DebugDirectivesOnly ||
           (DebugInfoKind == codegenoptions::DebugLineTablesOnly &&
            SplitDWARFInlining))
         DwarfFission = DwarfFissionKind::None;
     }
-  }
+  } else
+    DwarfFission = DwarfFissionKind::None;
 
   // If a debugger tuning argument appeared, remember it.
   if (const Arg *A =
           Args.getLastArg(options::OPT_gTune_Group, options::OPT_ggdbN_Group)) {
     if (checkDebugInfoOption(A, Args, D, TC)) {
       if (A->getOption().matches(options::OPT_glldb))
         DebuggerTuning = llvm::DebuggerKind::LLDB;
       else if (A->getOption().matches(options::OPT_gsce))

clang/test/Driver/debug-options.c

 // RUN: %clang -### -c -ggnu-pubnames -gno-gnu-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -ggnu-pubnames -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
 // RUN: %clang -### -c -gpubnames %s 2>&1 | FileCheck -check-prefix=PUB %s
 // RUN: %clang -### -c -ggdb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -gpubnames -gno-gnu-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -gpubnames -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gsplit-dwarf %s 2>&1 | FileCheck -check-prefix=GPUB %s
-// RUN: %clang -### -c -gsplit-dwarf -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
+// RUN: %clang -### -c -gsplit-dwarf -g %s 2>&1 | FileCheck -check-prefix=GPUB %s
+// RUN: %clang -### -c -gsplit-dwarf -g -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
 // RUN: %clang -### -c -fdebug-ranges-base-address %s 2>&1 | FileCheck -check-prefix=RNGBSE %s
 // RUN: %clang -### -c %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 // RUN: %clang -### -c -fdebug-ranges-base-address -fno-debug-ranges-base-address %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 //
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //

clang/test/Driver/fuchsia.c

 // RUN:     -flto=thin -flto-jobs=8 2>&1 \
 // RUN:     -fuse-ld=lld \
 // RUN:     | FileCheck %s -check-prefix=CHECK-THINLTO
 // CHECK-THINLTO: "-plugin-opt=mcpu=x86-64"
 // CHECK-THINLTO: "-plugin-opt=thinlto"
 // CHECK-THINLTO: "-plugin-opt=jobs=8"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
-// RUN:     -gsplit-dwarf -c %s 2>&1 \
+// RUN:     -gsplit-dwarf -g -c %s 2>&1 \
 // RUN:     | FileCheck %s -check-prefix=CHECK-SPLIT-DWARF
 // CHECK-SPLIT-DWARF: "-split-dwarf-output" "fuchsia.dwo"

clang/test/Driver/split-debug.c

 // Check that we split debug output properly
 //
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -c -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -g -gsplit-dwarf -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-ACTIONS < %t %s
 //
 // CHECK-ACTIONS: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -c -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-ACTIONS < %t %s
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=split -c -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=split -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-ACTIONS < %t %s
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=single -c -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=single -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-ACTIONS-SINGLE-SPLIT < %t %s
 //
 // CHECK-ACTIONS-SINGLE-SPLIT: "-split-dwarf-file" "split-debug.o"
 // CHECK-ACTIONS-SINGLE-SPLIT-NOT: "-split-dwarf-output"
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=single -c -### -o %tfoo.o %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=single -g -c -### -o %tfoo.o %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-SINGLE-SPLIT-FILENAME < %t %s
 //
 // CHECK-SINGLE-SPLIT-FILENAME: "-split-dwarf-file" "{{.*}}foo.o"
 // CHECK-SINGLE-SPLIT-FILENAME-NOT: "-split-dwarf-output"
 
-// RUN: %clang -target x86_64-macosx -gsplit-dwarf -c -### %s 2> %t
+/// -gsplit-dwarf requires -g. It is also a no-op on a non-ELF platform.
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -c -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
+// RUN: %clang -target x86_64-macosx -gsplit-dwarf -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
 //
-// CHECK-NO-ACTIONS-NOT: -split-dwarf
+// CHECK-NO-ACTIONS-NOT: "-split-dwarf
 
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -o Bad.x -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g -o Bad.x -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-BAD < %t %s
 //
 // CHECK-BAD-NOT: "Bad.dwo"
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -c -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-OPTION < %t %s
 //
-// RUN: %clang -target x86_64-pc-freebsd12 -gsplit-dwarf -c -### %s 2> %t
+// RUN: %clang -target x86_64-pc-freebsd12 -gsplit-dwarf -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-OPTION < %t %s
 //
-// RUN: %clang -target amdgcn-amd-amdhsa -gsplit-dwarf -c -### %s 2> %t
+// RUN: %clang -target amdgcn-amd-amdhsa -gsplit-dwarf -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-OPTION < %t %s
 //
 // CHECK-OPTION: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -S -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-ASM < %t %s
 //
 // CHECK-ASM-NOT: objcopy
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -no-integrated-as -gsplit-dwarf -c -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -no-integrated-as -gsplit-dwarf -g -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-IAS < %t %s
 //
 // CHECK-IAS: objcopy
 
 // RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gmlt -fno-split-dwarf-inlining -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-GMLT-WITH-SPLIT < %t %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -gmlt -gsplit-dwarf -fno-split-dwarf-inlining -S -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-GMLT-WITH-SPLIT < %t %s
 //
 // CHECK-GMLT-WITH-SPLIT: "-debug-info-kind=line-tables-only"
 // CHECK-GMLT-WITH-SPLIT: "-split-dwarf-file"
 // CHECK-GMLT-WITH-SPLIT: "-split-dwarf-output"
 
 // RUN: %clang -target x86_64-unknown-linux-gnu -g -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-NOINLINE-WITHOUT-SPLIT < %t %s
 //
 // RUN: %clang -target x86_64-unknown-linux-gnu -g -fno-split-dwarf-inlining -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-NOINLINE-WITHOUT-SPLIT < %t %s
 //
 // CHECK-NOINLINE-WITHOUT-SPLIT: "-fno-split-dwarf-inlining"
 // CHECK-NOINLINE-WITHOUT-SPLIT: "-debug-info-kind=limited"
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gmlt -gsplit-dwarf -fno-split-dwarf-inlining -S -### %s 2> %t
-// RUN: FileCheck -check-prefix=CHECK-SPLIT-WITH-GMLT < %t %s
-//
-// CHECK-SPLIT-WITH-GMLT: "-debug-info-kind=limited"
-// CHECK-SPLIT-WITH-GMLT: "-split-dwarf-output"
-
-// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -fno-split-dwarf-inlining -S -### %s 2> %t
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g -fno-split-dwarf-inlining -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-SPLIT-WITH-NOINL < %t %s
 //
 // CHECK-SPLIT-WITH-NOINL: "-debug-info-kind=limited"
 // CHECK-SPLIT-WITH-NOINL: "-split-dwarf-output"
 
 // RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gmlt -fsplit-dwarf-inlining -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-GMLT-OVER-SPLIT < %t %s
 //
 // CHECK-GMLT-OVER-SPLIT: "-debug-info-kind=line-tables-only"
 // CHECK-GMLT-OVER-SPLIT-NOT: "-split-dwarf-file"
 // CHECK-GMLT-OVER-SPLIT-NOT: "-split-dwarf-output"
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -gmlt -gsplit-dwarf -S -### %s 2> %t
-// RUN: FileCheck -check-prefix=CHECK-SPLIT-OVER-GMLT < %t %s
-//
-// CHECK-SPLIT-OVER-GMLT: "-debug-info-kind=limited"
-// CHECK-SPLIT-OVER-GMLT: "-split-dwarf-file"
-// CHECK-SPLIT-OVER-GMLT: "-split-dwarf-output"
-
 // RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g0 -fno-split-dwarf-inlining -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-G0-OVER-SPLIT < %t %s
 //
 // CHECK-G0-OVER-SPLIT-NOT: "-debug-info-kind
 // CHECK-G0-OVER-SPLIT-NOT: "-split-dwarf-file"
 // CHECK-G0-OVER-SPLIT-NOT: "-split-dwarf-output"
 
 // RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -g0 -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-G0-OVER-SPLIT < %t %s
 // RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf=split -g0 -S -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-G0-OVER-SPLIT < %t %s
-//
+// RUN: %clang -target x86_64-unknown-linux-gnu -g0 -gsplit-dwarf -S -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-G0-OVER-SPLIT < %t %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -g0 -gsplit-dwarf=split -S -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-G0-OVER-SPLIT < %t %s
+
 // CHECK-G0-OVER-SPLIT-NOT: "-debug-info-kind
 // CHECK-G0-OVER-SPLIT-NOT: "-split-dwarf-file"
 // CHECK-G0-OVER-SPLIT-NOT: "-split-dwarf-output"
-
-// RUN: %clang -target x86_64-unknown-linux-gnu -g0 -gsplit-dwarf -S -### %s 2> %t
-// RUN: FileCheck -check-prefix=CHECK-SPLIT-OVER-G0 < %t %s
-// RUN: %clang -target x86_64-unknown-linux-gnu -g0 -gsplit-dwarf=split -S -### %s 2> %t
-// RUN: FileCheck -check-prefix=CHECK-SPLIT-OVER-G0 < %t %s
-//
-// CHECK-SPLIT-OVER-G0: "-debug-info-kind=limited"
-// CHECK-SPLIT-OVER-G0: "-split-dwarf-file"
-// CHECK-SPLIT-OVER-G0: "-split-dwarf-output"