Cross-Compiling for Windows breaks error stack traces

[nolanderc]

Zig Version

0.10.0-dev.3857+10e11b60e

Steps to Reproduce

mkdir zig-test && cd zig-test
zig init-exe

and replace src/main.zig with the following:

const std = @import("std");

pub fn main() !void {
    std.log.info("running on thread {}", .{std.Thread.getCurrentId()});
    return error.Whatever;
}

Then build the program on a non-windows OS (tested using Ubuntu 20.04 through WSL2):

zig build -Dtarget=x86_64-windows

Expected Behavior

The program should terminate with a message containing the error and a stack trace showing where the error originated from. For example, this is the result when on WSL2 using zig build run:

info: running on thread 24663
error: Whatever
/home/christofer/dev/tmp/zig-test/src/main.zig:5:5: 0x20d416 in main (zig-test)
    return error.Whatever;
    ^

Actual Behavior

Attempting to run this program on a Windows machine (tested on Windows 11 build 22000.856) produces the following output:

info: running on thread 32448
error: Whatever
thread 32448 panic: reached unreachable code
Panicked during a panic. Aborting.

[nolanderc]

I have a hunch that this might be related to #8205, since all sources live in WSL and thus use UNC paths when creating the stack trace.

[squeek502]

Now that #15768 is merged, could anyone using WSL2 test to see if this was fixed by it?

[star-tek-mb]

Now that #15768 is merged, could anyone using WSL2 test to see if this was fixed by it?

Stack traces are still broken like that on WSL2:
???:?:?: 0x7ff77c7d33a2 in ??? (test.exe)

[kcbanner]

I looked into this, and it's happening because the PDB path is of the form /home/kcbanner/temp/12729/zig-cache/o/84727f745cb2d4778303a1b5b8068004/12729.pdb.

After the call to fs.path.resolve in readCoffDebugInfo, path is \home\kcbanner\temp\12729\zig-cache\o\84727f745cb2d4778303a1b5b8068004\12729.pdb. This then fails to open in the call to openFile in Pdb.init.

[kcbanner]

There is an additional problem, even if you do find the PDB by doing something like:

        const pdb_paths = [_][]const u8{
            path,
            fs.path.basename(path),
        };

        di.debug_data = PdbOrDwarf{ .pdb = undefined };
        di.debug_data.pdb = for (pdb_paths) |pdb_path| {
            break pdb.Pdb.init(allocator, pdb_path) catch |err| switch (err) {
                error.FileNotFound, error.IsDir => continue,
                else => return err,
            };
        } else return error.MissingDebugInfo;

All the source paths are also unix-style, ie:

So to support this we'd need to have some path-mapping heuristic for source files as well.