MinGW can't symbolize system libraries

[alexcrichton]

Running cargo run --example backtrace the last two frames are <unknown>. They come from kernel32.dll and ntdll.dll I believe, and they should have symbols (they do on MSVC at least). I'm not sure if we're missing the symbol table on these DLL files or misinterpreting them, but either way I'm pretty certain the symbol is somewhere on the filesystem so we should be able to find it!

[workingjubilee]

Hm. Uh.

@mati865 Is there something for us to fix here or is this windows-gnu having a skill issue?

[mati865]

No idea, but I think the same backend is used by MSVC, so it would make sense if they worked.

[bjorn3]

The mingw targets use addr2line for symbolizing DWARF debuginfo, while the msvc targets use dbghelp for symbolizing PDB debuginfo. Maybe for system libraries only dbghelp knows how to get symbol names?

[mati865]

Oh, so all Windows targets use dbghelp to obtain backtrace and then GNU and LLVM use different tools to symbolize it?

backtrace-rs/src/backtrace/mod.rs

Line 190 in 5e05efa

} else if #[cfg(all(windows, not(target_vendor = "uwp")))] {

That could explain the difference. I don't know addr2line code but Binutils (and LLVM tools mimicking them like llvm-objdump) all fail to read symbol tables from system libraries.
COFF dedicated tools like llvm-readobj can print exports, and many other things but symbols table is still empty. Possibly those DLLs need some special casing.

[ChrisDenton]

The "native" (aka system) way to do debug symbols is to have a separate PDB file containing the symbols. Mingw targets use DWARF which is a different debug format and is embedded (at least by default, I'm not sure if split-debug is supported).

To thread the needle here we would ideally need mingw targets to read the DWARF if available and then fallback to the windows-msvc method if not. But I don't know how practical that it is to switch between them.

[workingjubilee]

this sounds so fucky.