Incorrect file paths in DWARF debug info

[leecannon]

Zig Version

0.12.0-dev.878+7abf9b3a8

Steps to Reproduce and Observed Behavior

Sorry, I was unable to replicate the issue with a reduction.

1. git clone https://github.com/CascadeOS/CascadeOS.git
2. cd CascadeOS
3. zig build kernel_x86_64
4. llvm-dwarfdump zig-out/x86_64/kernel --name=page_size

With 0.12.0-dev.878+7abf9b3a8:

$ llvm-dwarfdump zig-out/x86_64/kernel --name=page_size
zig-out/x86_64/kernel:	file format elf64-x86-64

0x0000097b: DW_TAG_variable
              DW_AT_name	("page_size")
              DW_AT_type	(0x00000863 "size.Size")
              DW_AT_decl_file	("/home/lee/src/CascadeOS/kernel/arch/x86_64/arch/x86_64/setup.zig")
              DW_AT_decl_line	(21)
              DW_AT_linkage_name	("arch.x86_64.setup.page_size")

With 0.12.0-dev.819+75b48ef50:

$ llvm-dwarfdump zig-out/x86_64/kernel --name=page_size
zig-out/x86_64/kernel:	file format elf64-x86-64

0x0000097b: DW_TAG_variable
              DW_AT_name	("page_size")
              DW_AT_type	(0x00000863 "size.Size")
              DW_AT_decl_file	("/home/lee/src/CascadeOS/kernel/arch/x86_64/setup.zig")
              DW_AT_decl_line	(21)
              DW_AT_linkage_name	("arch.x86_64.setup.page_size")

The issue only seems to affect files in subdirectories.

Expected Behavior

Correct file paths in debug info.

[davidgmbb]

Right now I was affected by the same issue. It looks like some directories are duplicated in the DWARF debug info:

#9  0x00000000002b63f3 in frontend.semantic_analyzer.initialize (compilation=0x7ffff7ff8000, module=0x7ffff7ff3000, package=0x7ffff7fed000, file_index=2147483648)
    at /home/david/dev/compiler/src/frontend/frontend/semantic_analyzer.zig:1145
1145    /home/david/dev/compiler/src/frontend/frontend/semantic_analyzer.zig: No such file or directory.

[davidgmbb]

I'd dare to say this is the problematic commit, since it's the one touching file paths for LLVM codegen debug information:
35d81c9

[squeek502]

This, or something like it, affects DWARF debug info more generally, here's a minimal reproduction:

pub fn main() !void {
    return error.Something;
}

$ zig build-exe test.zig
$ ./test
error: Something
???:?:?: 0x21db38 in main (test)

It seems to have regressed in #17392 as @davidgm94 suggested. Reverting to before that PR was merged fixes it:

$ zig build-exe test.zig
$ ./test
error: Something
/home/ryan/Programming/zig/tmp/test.zig:4:5: 0x21db38 in main (test)
    return error.Something;
    ^

[squeek502]

Another caveat: this only seems to affect certain files, for example if you panic during a test, then source lines get printed for zig lib files but not the local file:

test "error" {
    @panic("oh no");
}

$ zig test test.zig
Test [1/1] test.error... thread 227764 panic: oh no
/home/ryan/Programming/zig/zig/lib/test.zig:2:5: 0x223825 in test.error (test)
/home/ryan/Programming/zig/zig/lib/test_runner.zig:181:28: 0x22c90d in mainTerminal (test)
        } else test_fn.func();
                           ^
/home/ryan/Programming/zig/zig/lib/test_runner.zig:36:28: 0x22485a in main (test)
        return mainTerminal();
                           ^
/home/ryan/Programming/zig/zig/lib/std/start.zig:573:22: 0x223d5c in posixCallMainAndExit (test)
            root.main();
                     ^
/home/ryan/Programming/zig/zig/lib/std/start.zig:251:5: 0x2238b1 in _start (test)
    asm volatile (switch (native_arch) {
    ^
???:?:?: 0x0 in ??? (???)

Before #17392:

$ zig test test.zig
Test [1/1] test.error... thread 227895 panic: oh no
/home/ryan/Programming/zig/tmp/test.zig:2:5: 0x223825 in test.error (test)
    @panic("oh no");
    ^
/home/ryan/Programming/zig/zig/lib/test_runner.zig:181:28: 0x22c90d in mainTerminal (test)
        } else test_fn.func();
                           ^
/home/ryan/Programming/zig/zig/lib/test_runner.zig:36:28: 0x22485a in main (test)
        return mainTerminal();
                           ^
/home/ryan/Programming/zig/zig/lib/std/start.zig:369:22: 0x223d5c in posixCallMainAndExit (test)
    while (envp_optional[envp_count]) |_| : (envp_count += 1) {}
                     ^
/home/ryan/Programming/zig/zig/lib/std/start.zig:251:5: 0x2238b1 in _start (test)
    asm volatile (switch (native_arch) {
    ^
???:?:?: 0x0 in ??? (???)

[andrewrk]

I noticed sub_path being used twice here, and fixed it like this:

--- a/src/codegen/llvm.zig
+++ b/src/codegen/llvm.zig
@@ -1840,7 +1840,8 @@ pub const Object = struct {
             const dir_path = try file.mod.root.joinStringZ(gpa, sub_path);
             if (std.fs.path.isAbsolute(dir_path)) break :d dir_path;
             const abs = std.fs.realpath(dir_path, &buffer) catch break :d dir_path;
-            break :d try std.fs.path.joinZ(gpa, &.{ abs, sub_path });
+            gpa.free(dir_path);
+            break :d try gpa.dupeZ(u8, abs);
         };
         defer gpa.free(dir_path_z);
         const sub_file_path_z = try gpa.dupeZ(u8, std.fs.path.basename(file.sub_file_path));

but that does not seem to be the full story since stack traces are still broken after this fix.

[andrewrk]

@@ -911,6 +911,9 @@ pub const Object = struct {
                     break :blk try builder.gpa.dupeZ(u8, cwd);
                 };
                 defer builder.gpa.free(compile_unit_dir_z);
+                std.debug.print("di compile unit = '{s}'\n", .{
+                    compile_unit_dir_z,
+                });

                 builder.llvm.di_compile_unit = builder.llvm.di_builder.?.createCompileUnit(
                     DW.LANG.C99,

With this line traced we see before/after:

-di compile unit = '/home/andy/dev/zig/build-release'
-di compile unit = '/home/andy/dev/zig/lib'
+di compile unit = ''
+di compile unit = '/home/andy/dev/zig/lib'

So it looks like the remaining issue is that empty string needs to get resolved to an absolute path. I still don't necessarily agree with using absolute paths here, but let me fix the regression and then deal with that idea separately.

[andrewrk]

Oh, I already wrote this up: #16571