[elf] -gsplit-dwarf leaves the resulting file in the cache dir

[motiejus]

Zig Version

0.10.0-dev.2473+e498fb155

Steps to Reproduce

A test file for everything:

#include <stdio.h>
#include <features.h>
int main() {
    #ifdef __GLIBC__
    printf("glibc_%d.%d\n", __GLIBC__, __GLIBC_MINOR__);
    #else
    printf("non-glibc\n");
    #endif
    return 0;
}

Expected Behavior

main.dwo appears in the working directory. Like with clang-13:

$ clang-13 main.c -ggdb3 -gsplit-dwarf -o main.clang-13
$ ls -lh main*
-rwxr-xr-x 1 motiejus engineering 17K Jun 13 13:51 main.clang-13
-rw-r--r-- 1 motiejus engineering 197 Jun 13 13:28 main.c
-rw-r--r-- 1 motiejus engineering 712 Jun 13 13:51 main.dwo

Actual Behavior

When compiled with zig cc, the dwo file is not placed to the current directory:

$ zig cc  main.c -ggdb3 -gsplit-dwarf -o main.zigcc
$ ls -lh main* 
-rwxr-xr-x 1 motiejus engineering 5.4K Jun 13 13:52 main.zigcc
-rw-r--r-- 1 motiejus engineering  197 Jun 13 13:28 main.c

The resulting binary points to main.dwo in zig's cache dir:

$ readelf -wi main.zig-cc |& head -1                                                                   
main: Found separate debug object file: /home/motiejus/.cache/zig/tmp/b676a2799c666cc3-main.dwo
$ strings main.zig-cc | grep dwo
/home/motiejus/.cache/zig/tmp/38be76f262cfa3bb-main.dwo

Sure enough, the file in /home/motiejus/.cache/zig/tmp/38be76f262cfa3bb-main.dwo is correct. Point being: copying the file is not enough; the dwo file path in the resulting object file needs to be updated accordingly.

For the record, the clang-13 version points to main.dwo in the same directory:

$ strings main.clang-13 | grep dwo
main.dwo

[motiejus]

Also see #11194 (comment): zig cc -gsplit-dwarf does not actually move the debug info to the .dwo file; it merely copies it, defeating the purpose of -gsplit-dwarf.