Set path of the compile unit to the source directory

[nagisa]

As part of the effort to implement split dwarf debug info, we ended up
setting the compile unit location to the output directory rather than
the source directory. Furthermore, it seems like we failed to remap the
prefixes for this as well!

The desired behaviour is to instead set the DW_AT_GNU_dwo_name to a
path relative to compiler's working directory. This still allows
debuggers to find the split dwarf files, while not changing the
behaviour of the code that is compiling with regular debug info, and not
changing the compiler's behaviour with regards to reproducibility.

Fixes #82074

cc @alexcrichton @davidtwco

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[davidtwco]

r? @davidtwco

[davidtwco]

r=me unless fixing the test failure requires sufficient changes to warrant another look.

[nagisa]

Huh, so what's happening is that llvm-dwp is naively concatenating DW_AT_comp_dir + DW_AT_GNU_dwo_name from DW_TAG_compile_unit. This issue is also reproducible with clang and gcc:

$ clang -gsplit-dwarf /tmp/banana/test.c -c -o /tmp/outdir/foo.o
$ clang outdir/foo.o -o outdir/hm
$ llvm-dwarfdump outdir/hm | grep -C5 foo.dwo

0x00002114: DW_TAG_compile_unit
              DW_AT_stmt_list	(0x000005ae)
              DW_AT_comp_dir	("/tmp")
              DW_AT_GNU_pubnames	(true)
              DW_AT_GNU_dwo_name	("/tmp/outdir/foo.dwo")
              DW_AT_GNU_dwo_id	(0xde4d396f3bf0e257)
              DW_AT_low_pc	(0x0000000000401100)
              DW_AT_high_pc	(0x0000000000401103)
              DW_AT_GNU_addr_base	(0x00000000)
0x00002139: Compile Unit: length = 0x0000001e, format = DWARF32, version = 0x0002, abbr_offset = 0x03c0, addr_size = 0x08 (next unit at 0x0000215b)
$ strace -o trace llvm-dwp -e outdir/hm -o outdir/hm.dwp
error: No such file or directory
$ cat trace | grep foo.dwo
openat(AT_FDCWD, "/tmp/tmp/outdir/foo.dwo", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

From what I can tell the right place to solve this would be in the llvm-dwp tool itself.

[nagisa]

@bors r=davidtwco rollup=never

[bors]

📌 Commit 956b5ce7a12ba82163dc835a43421d5056800578 has been approved by davidtwco

[bors]

⌛ Testing commit 956b5ce7a12ba82163dc835a43421d5056800578 with merge aaa3ae5fd54761939253c04f4f1e0c238045480c...

[jethrogb]

Please r-! This is pointing the llvm-project submodule at a commit that does not exist in any branches on https://github.com/rust-lang/llvm-project/

[nagisa]

@bors r-

[nagisa]

@bors r=davidtwco

[bors]

📌 Commit beb3f1e885c619f7964a093d72d56446e9c0bdae has been approved by davidtwco

[bors]

⌛ Testing commit beb3f1e885c619f7964a093d72d56446e9c0bdae with merge 79516cd72305b88a97aefb8071e57e71693a02a4...

[bors]

💔 Test failed - checks-actions

[nagisa]

@bors r=davidtwco

[bors]

📌 Commit 925ed48 has been approved by davidtwco

[bors]

⌛ Testing commit 925ed48 with merge 446d453...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 446d453 to master...