[Driver] Add -dumpdir and change -gsplit-dwarf .dwo names for linking

[MaskRay]

Summary

When the final phase is linking, Clang currently places .dwo files in the
current directory (like the -c behavior for multiple inputs).
Strangely, -fdebug-compilation-dir=/-ffile-compilation-dir= is considered, which
is untested.

GCC has a more useful behavior that derives auxiliary filenames from the final
output (-o).

gcc -c -g -gsplit-dwarf d/a.c d/b.c      # a.dwo b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c -o e/x  # e/x-a.dwo e/x-b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c         # a-a.dwo a-b.dwo

Port a useful subset of GCC behaviors that are easy to describe to Clang.

• Add a driver and cc1 option -dumpdir
• When the final phase is link, add a default -dumpdir if not specified by the user
• Forward -dumpdir to -cc1 command lines
• tools::SplitDebugName prefers -dumpdir when constructing the .dwo filename

GCC provides -dumpbase. If we use just one of -dumpdir and -dumpbase,
-dumpbase isn't very useful as it appends a dash.

gcc -g -gsplit-dwarf -dumpdir e d/a.c   # ea.dwo
gcc -g -gsplit-dwarf -dumpdir e/ d/a.c  # e/a.dwo
gcc -g -gsplit-dwarf -dumpbase e d/a.c  # e-a.dwo
gcc -g -gsplit-dwarf -dumpbase e/ d/a.c # e/-a.dwo

If we specify both -dumpdir and -dumpbase, we can avoid the influence of the
source filename when there is one input file.

gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c        # f/x.dwo
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c d/b.c  # f/x-a.dwo f/x-b.dwo

Given the above examples, I think -dumpbase is not useful.

GCC -save-temps has interesting interaction with -dumpdir as -save-temps
generated files are considered auxiliary files like .dwo files.

For Clang, with this patch, -save-temps and -dumpdir are orthogonal, which is
easier to explain.

gcc -g -gsplit-dwarf d/a.c -o e/x -dumpdir f/ -save-temps=obj # e/a.{i,s,o,dwo}
gcc -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # f/a.{i,s,o,dwo}

clang -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # e/a.{i,s,o} f/a.dwo

[scott.linder]

I'm a bit confused after trying to work out the rules for the GCC version of -dumpdir over at https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpdir but it at least seems like our version is a subset of theirs.

Do we support any of the other -dump* options GCC does? E.g. https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpbase and https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpbase-ext ? I don't think we need to in order to add and use -dumpdir, but they do have a somewhat unique inter-dependence in that the exact value of one can cause another to be completely ignored.

Also, would it be worth adding tests for the following cases:

It defaults to the location of the output file, unless the output file is a special file like /dev/null. Options -save-temps=cwd and -save-temps=obj override this default, just like an explicit -dumpdir option. In case multiple such options are given, the last one prevails:

clang/lib/Driver/ToolChains/CommonArgs.cpp

1250–1266

There is an extra check for dumpdir and a string copy in the OPT_c case, maybe it can just move past that case?

[MaskRay]

In D149193#4297043, @scott.linder wrote:

I'm a bit confused after trying to work out the rules for the GCC version of -dumpdir over at https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpdir but it at least seems like our version is a subset of theirs.

Yes, it's quite complex.... I think we'll just port the reasonable subset of rules (like clang -g -gsplit-dwarf a.c b.c -o out, but not the more complex ones)...

It seems that -dumpdir is the most useful option. -dumpbase appends a -, which can be undesired, if we intend to expose an option to place auxiliary files.

gcc -g -gsplit-dwarf -dumpdir f a.c => fa.dwo
gcc -g -gsplit-dwarf -dumpdir f/ a.c => f/a.dwo
gcc -g -gsplit-dwarf -dumpbase f a.c => f-a.dwo
gcc -g -gsplit-dwarf -dumpbase f/ a.c => f/-a.dwo

What's more complex is that -dumpdir and -dumpbase can be used together. I have played a bit and haven't thought of a case that the combination is useful.

Do we support any of the other -dump* options GCC does? E.g. https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpbase and https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpbase-ext ? I don't think we need to in order to add and use -dumpdir, but they do have a somewhat unique inter-dependence in that the exact value of one can cause another to be completely ignored.

We don't. Having just -dumpdir perhaps will be useful enough when we make -save-temps inter-operate with -dumpdir (control *.i, *.s, *.bc, etc)

Also, would it be worth adding tests for the following cases:

It defaults to the location of the output file, unless the output file is a special file like /dev/null. Options -save-temps=cwd and -save-temps=obj override this default, just like an explicit -dumpdir option. In case multiple such options are given, the last one prevails:

GCC special cases /dev/null, but it doesn't treat other special files differently.

gcc -g -gsplit-dwarf a.c -o /dev/null  # a.dwo
gcc -g -gsplit-dwarf a.c -o /dev/zero  # /dev/zero-a.dwo (likely fail to create)
gcc -g -gsplit-dwarf a.c -o /dev/zero -save-temp=obj  # /dev/null-a.i (likely fail to create)

I suggest that we don't have the special rule.

clang -g -gsplit-dwarf a.c -o /dev/null  # /dev/null-a.dwo (likely fail to create)

[MaskRay]

add notes and more test

[MaskRay]

expose -dumpdir
add release notes

[dblaikie]

clang/lib/Driver/Driver.cpp

3884

would be nice to have this "a" derive from wherever we hardcode "a.out" as the default output rather than independently hardcoded here?

& what does GCC do when the -o value has a . in it? (if you use -o a.out do you get the same a-x.dwo behavior, or do you get a.out-x.dwo?)

clang/lib/Driver/ToolChains/CommonArgs.cpp

1261

I was going to suggest we shouldn't remove this functionality without checking who implemented/whether they rely on it (despite it being untested)

Looks like it went in in some of the earliest patches from Google for Split DWARF ( 248357f62418831c7be9d43d96860b52aae1ef56 ).

We do use -fdebug-compilation-dir at Google, but I think we just set it to . anyway, so for that use case it'd be a no-op anyway, I think? Might want to test this patch internally just to be sure, though.

Though perhaps we never hit this path, because we'll always be building with -o and -c which should hit the if above?

[MaskRay]

clang/lib/Driver/Driver.cpp

3884

We can use llvm::sys::path::stem(getDefaultImageName()), but I feel that this just complicates the code.
The default is a.out or a.exe. If a downstream platform decides to deviate and use another filename, say, b.out. We will use -dumpdir b- on this platform and -dumpdir a- on everything else. I think they will likely be fine with a- even if they don't use a as the stem name of the default image...

GCC generally doesn't special case . in -o for linking, but the a.out filename is different.

gcc -g -gsplit-dwarf d/a.c.c -o e/x.out  # e/x.out-a.dwo
gcc -g -gsplit-dwarf d/a.c.c -o e/a.out  # e/a-a.dwo

I think Clang should not special case a.out.

[scott.linder]

clang/lib/Driver/Driver.cpp

3884

GCC distinguishes between "dump" and "auxiliary" outputs, and in this case I think the "dump" outputs retain the basename-suffix (i.e. you get a.out<dumppfx>) whereas "auxiliary" outputs first strip the basename-suffix (i.e. you get a<dumppfx>). The basename-suffix itself can be specified explicitly via -dumpbase-ext, but it is inferred by default.

The naming for things adds to the for me:

• -dumpdir doesn't specifically/exclusively specify a "directory", it just specifies a prefix
• -dumpbase-ext only affects the output of non-dump, auxiliary files

I do worry that being close-but-not-quite like GCC here will cause headaches for someone, but I am also not excited about implementing the complexity of the GCC options.

[phosek]

Do we have any way to check if there are projects out there that use -dumpbase? It shouldn't be too difficult to support it, but we should find out first if it's needed.

[MaskRay]

In D149193#4300501, @phosek wrote:

Do we have any way to check if there are projects out there that use -dumpbase? It shouldn't be too difficult to support it, but we should find out first if it's needed.

I spot checked the very few items on https://sourcegraph.com/search?q=context:global+-dumpbase+&patternType=standard&sm=1&groupBy=repo and they don't like genuine use cases.

I think the main use case for -dumpbase is to entirely control the auxiliary file for -c and -S, but the addition of -dumpbase doesn't seem very useful to me...

gcc -c -g -gsplit-dwarf d/a.c -dumpdir f/ -dumpbase aa   # f/aa.dwo instead of f/a.dwo

clang/lib/Driver/Driver.cpp

3884

... I think the "dump" outputs retain the basename-suffix (i.e. you get a.out<dumppfx>) whereas "auxiliary" outputs first strip the basename-suffix (i.e. you get a<dumppfx>).

Confirmed.

gcc -g -fdump-rtl-all -gsplit-dwarf d/a.c -o e/x.out
ls e/x.out-a.c.338r.dfinish e/x.out-a.dwo

For dump output files, I think they all reside in developer options (https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html) not intended to be used by end users. They occasionally make incompatible changes in this area as well, e.g. https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546009.html simplified some rules.

It seems that if we just implement -dumpdir, we have gotten the good parts and we are probably done :)

[MaskRay]

I think the patch as-is implements all the useful parts of GCC's complex rules and in the absence of -dumpbase (we deliberately don't implement), the rule almost exactly matches GCC unless we do gcc -g -gsplit-dwarf d/a.c -o e/a.out (instead of other filenames).

https://maskray.me/blog/2023-04-25-compiler-output-files records all my findings.

clang/lib/Driver/ToolChains/CommonArgs.cpp

1261

We use the environment variable, if exists and is an absolute path, is used by GCC and Clang as a fallback when -fdebug-compilation-dir= is unspecified. As an example, PWD=/proc/self/cwd clang ....

I agree that for most(all?) split DWARF users will not see any difference since they always use -c -o and don't combine compilation and linking in one command.

[scott.linder]

In D149193#4300885, @MaskRay wrote:

I think the patch as-is implements all the useful parts of GCC's complex rules and in the absence of -dumpbase (we deliberately don't implement), the rule almost exactly matches GCC unless we do gcc -g -gsplit-dwarf d/a.c -o e/a.out (instead of other filenames).

https://maskray.me/blog/2023-04-25-compiler-output-files records all my findings.

I agree that the special-casing of a.out when explicitly specified is odd.

Another option to avoid any confusion or debates over exact behavior relative to GCC would be to just make our own option. Rather than add -dumpdir we could add -dump-prefix or something. I'm also OK with just implementing a simpler subset of the GCC options though (i.e. what you have already).

[MaskRay]

In D149193#4302337, @scott.linder wrote:

In D149193#4300885, @MaskRay wrote:

I think the patch as-is implements all the useful parts of GCC's complex rules and in the absence of -dumpbase (we deliberately don't implement), the rule almost exactly matches GCC unless we do gcc -g -gsplit-dwarf d/a.c -o e/a.out (instead of other filenames).

https://maskray.me/blog/2023-04-25-compiler-output-files records all my findings.

I agree that the special-casing of a.out when explicitly specified is odd.

Another option to avoid any confusion or debates over exact behavior relative to GCC would be to just make our own option. Rather than add -dumpdir we could add -dump-prefix or something. I'm also OK with just implementing a simpler subset of the GCC options though (i.e. what you have already).

I have thought about this option, using a name like --aux-prefix= (I'd prefer aux to dump), but since the behaviors are nearly identical (if we ignore the GCC -o d/a.out special case), I think using -dumpdir is still fine, and users won't need to remember two options when they have the needs.

I think the GCC -o e/a.out special case is a bug to detect gcc -g -gsplit-dwarf d/a.c (without -o; a.dwo). If the bug is fixed, its -dumpdir behavior should be identical (for all the experiments I have done) to what this patch implements.

[scott.linder]

I am OK to give LGTM, assuming the other reviewers don't still have reservations?

[dankm]

I certainly like the idea. I'll spend some time later looking at the implementation, but from a quick glance it looks good.

[dblaikie]

In D149193#4302981, @scott.linder wrote:

I am OK to give LGTM, assuming the other reviewers don't still have reservations?

Some - planning to get to this next week.

[MaskRay]

Thank you:)

[dblaikie]

I guess my main question is: What's the motivation for implementing this? Do you have a need/use for this? (it doesn't seem to be motivated by GCC compatibility - as discussed, looks like we're diverging in a bunch of ways from their behavior and the argument made that these are "developer" flags, so not a stable/compatible interface used across both compilers)

[MaskRay]

In D149193#4316293, @dblaikie wrote:

I guess my main question is: What's the motivation for implementing this? Do you have a need/use for this? (it doesn't seem to be motivated by GCC compatibility - as discussed, looks like we're diverging in a bunch of ways from their behavior and the argument made that these are "developer" flags, so not a stable/compatible interface used across both compilers)

This is a long-known problem that features with auxiliary output files go to strange directories (temporary directory, usually /tmp).
Among these options, the prominent ones are -gsplit-dwarf and -ftime-trace (clang -ftime-trace a.c b.c https://github.com/llvm/llvm-project/issues/57285).

By just implementing -dumpdir , we don't diverge in "a bunch ways". If GCC has fixed their -o d/a.out bug, our behavior should match theirs.

[MaskRay]

Ping:)

[dblaikie]

I agree that for most(all?) split DWARF users will not see any difference since they always use -c -o and don't combine compilation and linking in one command.

Given that, I'm not sure that this is worth implementing, but if it suits you I guess.

clang/lib/Driver/Driver.cpp

3884

We can use llvm::sys::path::stem(getDefaultImageName()), but I feel that this just complicates the code.

I think it'd be a bit better this way - otherways "a" looks pretty arbitrary. Is there some other reason it would be "a"? If it is derived from "a.out" I think having the code reflect that is helpful to the reader.

[MaskRay]

In D149193#4328452, @dblaikie wrote:

I agree that for most(all?) split DWARF users will not see any difference since they always use -c -o and don't combine compilation and linking in one command.

Given that, I'm not sure that this is worth implementing, but if it suits you I guess.

The split DWARF users are about production users.

There are command line users who do clang -g -gsplit-dwarf a.c b.c -o x and I have heard about questions that the .dwo files go to strange directories (usually /tmp) quite a few times.
Fixing -gsplit-dwarf helps set a baseline for other options like -ftime-trace (https://github.com/llvm/llvm-project/issues/57285).

[MaskRay]

use llvm::sys::path::stem(getDefaultImageName())

[scott.linder]

In D149193#4316293, @dblaikie wrote:

I guess my main question is: What's the motivation for implementing this? Do you have a need/use for this? (it doesn't seem to be motivated by GCC compatibility - as discussed, looks like we're diverging in a bunch of ways from their behavior and the argument made that these are "developer" flags, so not a stable/compatible interface used across both compilers)

Even if we only align the default behavior of Clang with the default behavior of GCC it seems like a win. AFAIU we could implement this without -dumpdir at all, but the baseline notion of being able to specify where to put auxiliary/dump files seems useful.

Do we need to match every quirk and add every other knob from GCC in order to use the same name? Is there precedent in terms of other options where Clang is close but opinionated about behavior relative to GCC?

[dblaikie]

In D149193#4328553, @MaskRay wrote:

In D149193#4328452, @dblaikie wrote:

I agree that for most(all?) split DWARF users will not see any difference since they always use -c -o and don't combine compilation and linking in one command.

Given that, I'm not sure that this is worth implementing, but if it suits you I guess.

The split DWARF users are about production users.

There are command line users who do clang -g -gsplit-dwarf a.c b.c -o x and I have heard about questions that the .dwo files go to strange directories (usually /tmp) quite a few times.
Fixing -gsplit-dwarf helps set a baseline for other options like -ftime-trace (https://github.com/llvm/llvm-project/issues/57285).

Fair enough

[dyung]

Hi @MaskRay, the test you modified clang/test/Driver/split-debug.c is failing on the PS5 Windows bot, can you take a look?

https://lab.llvm.org/buildbot/#/builders/216/builds/20981

# command stderr:
Z:\b\llvm-clang-x86_64-sie-win\llvm-project\clang\test\Driver\split-debug.c:72:21: error: SPLIT_LINK_NULL: expected string not found in input
// SPLIT_LINK_NULL: "-dumpdir" "/dev/null-"
                    ^
<stdin>:1:1: note: scanning from here
clang version 17.0.0 (https://github.com/llvm/llvm-project.git 16a0a69aadf1ad04efeaab9073bebdfb4b4fd34f)
^
<stdin>:5:130: note: possible intended match here
 "z:\\b\\llvm-clang-x86_64-sie-win\\build\\bin\\clang.exe" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-dumpdir" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "split-debug.c" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-debug-info-kind=constructor" "-dwarf-version=5" "-debugger-tuning=gdb" "-ggnu-pubnames" "-split-dwarf-file" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-split-dwarf-output" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-fcoverage-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-resource-dir" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17" "-internal-isystem" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17\\include" "-internal-isystem" "/usr/local/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\split-debug-c67aff.o" "-x" "c" "Z:\\b\\llvm-clang-x86_64-sie-win\\llvm-project\\clang\\test\\Driver\\split-debug.c"
                                                                                                                                 ^
Input file: <stdin>
Check file: Z:\b\llvm-clang-x86_64-sie-win\llvm-project\clang\test\Driver\split-debug.c
-dump-input=help explains the following input dump.
Input was:
<<<<<<
            1: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 16a0a69aadf1ad04efeaab9073bebdfb4b4fd34f) 
check:72'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
            2: Target: x86_64-unknown-linux-gnu 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            3: Thread model: posix 
check:72'0     ~~~~~~~~~~~~~~~~~~~~
            4: InstalledDir: z:\b\llvm-clang-x86_64-sie-win\build\bin 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5:  "z:\\b\\llvm-clang-x86_64-sie-win\\build\\bin\\clang.exe" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-dumpdir" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "split-debug.c" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-debug-info-kind=constructor" "-dwarf-version=5" "-debugger-tuning=gdb" "-ggnu-pubnames" "-split-dwarf-file" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-split-dwarf-output" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-fcoverage-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-resource-dir" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17" "-internal-isystem" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17\\include" "-internal-isystem" "/usr/local/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\split-debug-c67aff.o" "-x" "c" "Z:\\b\\llvm-clang-x86_64-sie-win\\llvm-project\\clang\\test\\Driver\\split-debug.c" 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:72'1                                                                                                                                      ?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         possible intended match
            6:  "ld" "-pie" "--hash-style=gnu" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy" "Scrt1.o" "crti.o" "crtbeginS.o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\split-debug-c67aff.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "crtendS.o" "crtn.o" 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>
error: command failed with exit status: 1
--
********************

[MaskRay]

In D149193#4331015, @dyung wrote:

Hi @MaskRay, the test you modified clang/test/Driver/split-debug.c is failing on the PS5 Windows bot, can you take a look?

https://lab.llvm.org/buildbot/#/builders/216/builds/20981

# command stderr:
Z:\b\llvm-clang-x86_64-sie-win\llvm-project\clang\test\Driver\split-debug.c:72:21: error: SPLIT_LINK_NULL: expected string not found in input
// SPLIT_LINK_NULL: "-dumpdir" "/dev/null-"
                    ^
<stdin>:1:1: note: scanning from here
clang version 17.0.0 (https://github.com/llvm/llvm-project.git 16a0a69aadf1ad04efeaab9073bebdfb4b4fd34f)
^
<stdin>:5:130: note: possible intended match here
 "z:\\b\\llvm-clang-x86_64-sie-win\\build\\bin\\clang.exe" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-dumpdir" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "split-debug.c" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-debug-info-kind=constructor" "-dwarf-version=5" "-debugger-tuning=gdb" "-ggnu-pubnames" "-split-dwarf-file" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-split-dwarf-output" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-fcoverage-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-resource-dir" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17" "-internal-isystem" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17\\include" "-internal-isystem" "/usr/local/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\split-debug-c67aff.o" "-x" "c" "Z:\\b\\llvm-clang-x86_64-sie-win\\llvm-project\\clang\\test\\Driver\\split-debug.c"
                                                                                                                                 ^
Input file: <stdin>
Check file: Z:\b\llvm-clang-x86_64-sie-win\llvm-project\clang\test\Driver\split-debug.c
-dump-input=help explains the following input dump.
Input was:
<<<<<<
            1: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 16a0a69aadf1ad04efeaab9073bebdfb4b4fd34f) 
check:72'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
            2: Target: x86_64-unknown-linux-gnu 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            3: Thread model: posix 
check:72'0     ~~~~~~~~~~~~~~~~~~~~
            4: InstalledDir: z:\b\llvm-clang-x86_64-sie-win\build\bin 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5:  "z:\\b\\llvm-clang-x86_64-sie-win\\build\\bin\\clang.exe" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-dumpdir" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "split-debug.c" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-debug-info-kind=constructor" "-dwarf-version=5" "-debugger-tuning=gdb" "-ggnu-pubnames" "-split-dwarf-file" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-split-dwarf-output" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy-split-debug.dwo" "-fcoverage-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-resource-dir" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17" "-internal-isystem" "z:\\b\\llvm-clang-x86_64-sie-win\\build\\lib\\clang\\17\\include" "-internal-isystem" "/usr/local/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir=Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\clang\\test\\Driver" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\split-debug-c67aff.o" "-x" "c" "Z:\\b\\llvm-clang-x86_64-sie-win\\llvm-project\\clang\\test\\Driver\\split-debug.c" 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:72'1                                                                                                                                      ?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         possible intended match
            6:  "ld" "-pie" "--hash-style=gnu" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\tmpq2vte1gy" "Scrt1.o" "crti.o" "crtbeginS.o" "C:\\Users\\buildbot\\AppData\\Local\\Temp\\lit-tmp-zjxfa_79\\split-debug-c67aff.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "crtendS.o" "crtn.o" 
check:72'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>
error: command failed with exit status: 1
--
********************

Sorry for the breakage. Should have been fixed by 8b16fc2e17c0149125e339f45d66f6c4eac9fec8 by using %if !system-windows.

lit emulates /dev/null on Windows, so we get something like "-dumpdir" "C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\lit-tmp-zu3jus70\\tmpzynja93m-".

This RUN line is mostly to document our behavior and is less interesting.

clang/include/clang/Driver/Options.td

def mrelocation_model : Separate<["-"], "mrelocation-model">,
   NormalizedValues<["Static", "PIC_", "ROPI", "RWPI", "ROPI_RWPI", "DynamicNoPIC"]>,
   MarshallingInfoEnum<CodeGenOpts<"RelocationModel">, "PIC_">;
 def debug_info_kind_EQ : Joined<["-"], "debug-info-kind=">;
 
 } // let Flags = [CC1Option, CC1AsOption, FC1Option, NoDriverOption]
 
 let Flags = [CC1Option, CC1AsOption, NoDriverOption] in {
 
+def dumpdir : Separate<["-"], "dumpdir">;
 def debug_info_macro : Flag<["-"], "debug-info-macro">,
   HelpText<"Emit macro debug information">,
   MarshallingInfoFlag<CodeGenOpts<"MacroDebugInfo">>;
 def default_function_attr : Separate<["-"], "default-function-attr">,
   HelpText<"Apply given attribute to all functions">,
   MarshallingInfoStringVector<CodeGenOpts<"DefaultFunctionAttrs">>;
 def dwarf_version_EQ : Joined<["-"], "dwarf-version=">,
   MarshallingInfoInt<CodeGenOpts<"DwarfVersion">>;

clang/lib/Driver/Driver.cpp

void Driver::handleArguments(Compilation &C, DerivedArgList &Args,
   if (FinalPhase == phases::Link) {
     // Emitting LLVM while linking disabled except in HIPAMD Toolchain
     if (Args.hasArg(options::OPT_emit_llvm) && !Args.hasArg(options::OPT_hip_link))
       Diag(clang::diag::err_drv_emit_llvm_link);
     if (IsCLMode() && LTOMode != LTOK_None &&
         !Args.getLastArgValue(options::OPT_fuse_ld_EQ)
              .equals_insensitive("lld"))
       Diag(clang::diag::err_drv_lto_without_lld);
+
+    // Prefer deriving auxiliary file names from the link output name.
+    Arg *Arg = Args.MakeSeparateArg(
+        nullptr, getOpts().getOption(options::OPT_dumpdir),
+        Args.MakeArgString(Args.getLastArgValue(options::OPT_o, "a") + "-"));
+    Arg->claim();
+    Args.append(Arg);
   }
 
   if (FinalPhase == phases::Preprocess || Args.hasArg(options::OPT__SLASH_Y_)) {
     // If only preprocessing or /Y- is used, all pch handling is disabled.
     // Rather than check for it everywhere, just remove clang-cl pch-related
     // flags here.
     Args.eraseArg(options::OPT__SLASH_Fp);
     Args.eraseArg(options::OPT__SLASH_Yc);

clang/lib/Driver/ToolChains/Clang.cpp

if (IsUsingLTO) {
         assert(LTOMode == LTOK_Full || LTOMode == LTOK_Thin);
         CmdArgs.push_back(Args.MakeArgString(
             Twine("-flto=") + (LTOMode == LTOK_Thin ? "thin" : "full")));
         CmdArgs.push_back("-flto-unit");
       }
     }
   }
 
+  Args.AddLastArg(CmdArgs, options::OPT_dumpdir);
+
   if (const Arg *A = Args.getLastArg(options::OPT_fthinlto_index_EQ)) {
     if (!types::isLLVMIR(Input.getType()))
       D.Diag(diag::err_drv_arg_requires_bitcode_input) << A->getAsString(Args);
     Args.AddLastArg(CmdArgs, options::OPT_fthinlto_index_EQ);
   }
 
   if (Args.getLastArg(options::OPT_fthin_link_bitcode_EQ))
     Args.AddLastArg(CmdArgs, options::OPT_fthin_link_bitcode_EQ);

clang/lib/Driver/ToolChains/CommonArgs.cpp

const char *tools::SplitDebugName(const JobAction &JA, const ArgList &Args,
   auto AddPostfix = [JA](auto &F) {
     if (JA.getOffloadingDeviceKind() == Action::OFK_HIP)
       F += (Twine("_") + JA.getOffloadingArch()).str();
     F += ".dwo";
   };
   if (Arg *A = Args.getLastArg(options::OPT_gsplit_dwarf_EQ))
     if (StringRef(A->getValue()) == "single")
       return Args.MakeArgString(Output.getFilename());
 
+  SmallString<128> T;
   Arg *FinalOutput = Args.getLastArg(options::OPT_o);
   if (FinalOutput && Args.hasArg(options::OPT_c)) {
-    SmallString<128> T(FinalOutput->getValue());
+    T = FinalOutput->getValue();
     llvm::sys::path::remove_filename(T);
     llvm::sys::path::append(T, llvm::sys::path::stem(FinalOutput->getValue()));
     AddPostfix(T);
     return Args.MakeArgString(T);
-  } else {
-    // Use the compilation dir.
-    Arg *A = Args.getLastArg(options::OPT_ffile_compilation_dir_EQ,
-                             options::OPT_fdebug_compilation_dir_EQ);
-    SmallString<128> T(A ? A->getValue() : "");
-    SmallString<128> F(llvm::sys::path::stem(Input.getBaseInput()));
-    AddPostfix(F);
-    T += F;
-    return Args.MakeArgString(T);
   }
+
+  if (const Arg *A = Args.getLastArg(options::OPT_dumpdir))
+    T = A->getValue();
+  T += llvm::sys::path::stem(Input.getBaseInput());
+  AddPostfix(T);
+  return Args.MakeArgString(T);
 }
 
 void tools::SplitDebugInfo(const ToolChain &TC, Compilation &C, const Tool &T,
                            const JobAction &JA, const ArgList &Args,
                            const InputInfo &Output, const char *OutFile) {
   ArgStringList ExtractArgs;
   ExtractArgs.push_back("--extract-dwo");
 
   ArgStringList StripArgs;

clang/test/Driver/hip-gsplit-dwarf-options.hip

 // REQUIRES: zlib, amdgpu-registered-target
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu -c \
 // RUN:   --offload-arch=gfx906:xnack+ %s -nogpulib -nogpuinc \
 // RUN:   --offload-arch=gfx900 \
 // RUN:   -ggdb -gsplit-dwarf 2>&1 | FileCheck %s
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu -c \
 // RUN:   -fgpu-rdc --offload-arch=gfx906:xnack+ %s -nogpulib -nogpuinc \
 // RUN:   --offload-arch=gfx900 \
 // RUN:   -ggdb -gsplit-dwarf 2>&1 | FileCheck %s
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu \
 // RUN:   --offload-arch=gfx906:xnack+ %s -nogpulib -nogpuinc \
 // RUN:   --offload-arch=gfx900 \
-// RUN:   -ggdb -gsplit-dwarf 2>&1 | FileCheck %s
+// RUN:   -ggdb -gsplit-dwarf 2>&1 | FileCheck %s --check-prefix=LINK
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu \
 // RUN:   -fgpu-rdc --offload-arch=gfx906:xnack+ %s -nogpulib -nogpuinc \
 // RUN:   --offload-arch=gfx900 \
-// RUN:   -ggdb -gsplit-dwarf 2>&1 | FileCheck %s
+// RUN:   -ggdb -gsplit-dwarf 2>&1 | FileCheck %s --check-prefix=LINK
 
 // CHECK-DAG: {{".*clang.*".* "-target-cpu" "gfx906".* "-split-dwarf-output" "hip-gsplit-dwarf-options_gfx906:xnack\+.dwo"}}
 // CHECK-DAG: {{".*clang.*".* "-target-cpu" "gfx900".* "-split-dwarf-output" "hip-gsplit-dwarf-options_gfx900.dwo"}}
 // CHECK-DAG: {{".*clang.*".* "-target-cpu" "x86-64".* "-split-dwarf-output" "hip-gsplit-dwarf-options.dwo"}}
+
+// LINK-DAG: {{".*clang.*".* "-target-cpu" "gfx906".* "-split-dwarf-output" "a-hip-gsplit-dwarf-options_gfx906:xnack\+.dwo"}}
+// LINK-DAG: {{".*clang.*".* "-target-cpu" "gfx900".* "-split-dwarf-output" "a-hip-gsplit-dwarf-options_gfx900.dwo"}}
+// LINK-DAG: {{".*clang.*".* "-target-cpu" "x86-64".* "-split-dwarf-output" "a-hip-gsplit-dwarf-options.dwo"}}

clang/test/Driver/split-debug.c

 /// Test -gsplit-dwarf and -gsplit-dwarf={split,single}.
 
 /// Interaction with -g (-g2).
 // RUN: %clang -### -c -target x86_64 -g -gsplit-dwarf %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 // RUN: %clang -### -c -target x86_64 -g2 -gsplit-dwarf %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 /// -gsplit-dwarf=split is equivalent to -gsplit-dwarf.
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 
 // INLINE:     "-fsplit-dwarf-inlining"
 // NOINLINE-NOT: "-fsplit-dwarf-inlining"
+// SPLIT-NOT:  "-dumpdir"
 // SPLIT:      "-debug-info-kind=constructor"
 // SPLIT-SAME: "-ggnu-pubnames"
 // SPLIT-SAME: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
 // RUN: %clang -### -c -target wasm32 -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=SPLIT
 // RUN: %clang -### -c -target amdgcn-amd-amdhsa -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=SPLIT
 
 /// -gsplit-dwarf is a no-op on a non-ELF platform.

 // SINGLE: "-split-dwarf-file" "split-debug.o"
 // SINGLE-NOT: "-split-dwarf-output"
 
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=single -g -o %tfoo.o %s 2>&1 | FileCheck %s --check-prefix=SINGLE_WITH_FILENAME
 
 // SINGLE_WITH_FILENAME: "-split-dwarf-file" "{{.*}}foo.o"
 // SINGLE_WITH_FILENAME-NOT: "-split-dwarf-output"
 
-/// Without -c, clang performs linking as well. The output is unchanged.
-// RUN: %clang -### -target x86_64-unknown-linux-gnu -gsplit-dwarf -g %s -o ignore.d 2>&1 | FileCheck %s --check-prefix=SPLIT
+/// If linking is the final phase, the .dwo filename is derived from -o (if specified) or "a".
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -gsplit-dwarf -g %s -o obj/out 2>&1 | FileCheck %s --check-prefix=SPLIT_LINK
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=SPLIT_LINK_A
+
+// SPLIT_LINK:      "-dumpdir" "obj/out-"
+// SPLIT_LINK:      "-debug-info-kind=constructor"
+// SPLIT_LINK-SAME: "-split-dwarf-file" "obj/out-split-debug.dwo" "-split-dwarf-output" "obj/out-split-debug.dwo"
+// SPLIT_LINK_A:      "-dumpdir" "a-"
+// SPLIT_LINK_A-SAME: "-split-dwarf-file" "a-split-debug.dwo" "-split-dwarf-output" "a-split-debug.dwo"
+
+/// GCC special cases /dev/null (HOST_BIT_BUCKET) but not other special files like /dev/zero.
+/// We don't apply special rules at all.
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -gsplit-dwarf -g %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=SPLIT_LINK_NULL
+
+// SPLIT_LINK_NULL:      "-dumpdir" "/dev/null-"
+// SPLIT_LINK_NULL-SAME: "-split-dwarf-output" "/dev/null-split-debug.dwo"
 
 /// -fsplit-dwarf-inlining
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -fsplit-dwarf-inlining %s 2>&1 | FileCheck %s --check-prefixes=INLINE,SPLIT
 
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -gno-pubnames %s 2>&1 | FileCheck %s --check-prefixes=NOPUBNAMES
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -gno-gnu-pubnames %s 2>&1 | FileCheck %s --check-prefixes=NOPUBNAMES
 // NOPUBNAMES:      "-debug-info-kind=constructor"
 // NOPUBNAMES-NOT:  "-ggnu-pubnames"