PE binaries with DWARF debug infos are only "half supported"

[Eijebong]

While dump_syms is able to get some info from those files, it can't get filenames nor function names from them.

Attached is a binary compiled from this:

#include <string>
#include <iostream>

std::string foo() {
    return "hey";
}
int main(int argc, char** argv) {
    std::cout << foo();
    return 0;
}

And symbols from the old and new dump_syms

text_mxe.zip Had to zip it so github would allow me to attach it...
new_dump_syms.txt
old_dump_syms.txt

[calixteman]

Info in this issue:
gimli-rs/object#40
could help.
@jan-auer, are these kind of PE handled in symbolic ?

[jan-auer]

No, we don't have support for DWARF PEs in symbolic, and I think it would be a great addition!

If I'm not mistaken, the changes needed for this should be managable: Add access to sections by name to the Pe type and then implement the Dwarf trait and return a DwarfDebugSession like for MachO and ELF. Is that something you'd like to create a PR for?

[calixteman]

@jan-auer I can try to find some time to do that, but I can't promise anything (I'm working on a totally unrelated stuff: pdf.js).
So if you have someone able to work on, please do it else file a bug on your repo and I'll fix it.
And yeah it doesn't seem too hard to deal with that stuff.
Thanks for answering anyway 😉

[jan-auer]

Thanks, I filed an issue now to track this. Ideally we should be able to look into this ourselves.

[jesse-pan]

Excuse me, is this problem solved now? I still can't get the file name and function name from the MingW64 compiled binary file using dump_syms(version 1.0.1).

[mstange]

Nope, getsentry/symbolic#352 is still open.

[acidtonic]

I am wondering if this will hit me because I have a rather complex multi-compiler application that uses both mingw64 (gtk3,gtkmm,gdlmm,cairo, other autotools libs) and visual studio 2022 (opencv4 with cuda, cudnn, thanks nvidia).

I thought I would be okay by building crashpad on the visual studio side, writing a C++ -> C shim to get past mangling, and then on the mingw64 side calling a C-only Extern to setup crashpad. It works and I get a correct registration.

Now when I try to build the symbol database the dump_syms tool on windows crashes with msdia140.dll issues but registering it or even placing it in the same folder did not fix that, so I landed here and built this rust version of dump_syms on my unix machine and copied the windows EXE's over thinking I could still build a symbol database...

Alas I only see a few symbols in the output and it seems most are not listed. Do I need to switch from gcc to clang or something else on the windows side? Unfortunately I am stuck in this split compiler configuration as I heavily use autotools/m4/gtk based libraries that do not build with visual studio (even with vcpkg or its friends).

Just curious, trying to find my way though this has been challenging but I think I am close.

[gabrielesvelto]

Now when I try to build the symbol database the dump_syms tool on windows crashes with msdia140.dll issues but registering it or even placing it in the same folder did not fix that, so I landed here and built this rust version of dump_syms on my unix machine and copied the windows EXE's over thinking I could still build a symbol database...

Note that you can build and use this dump_syms on Windows too, it's fully cross-platform.

Alas I only see a few symbols in the output and it seems most are not listed.

Yes, as per the comment above this is an issue in Symbolic which we use for reading debug information and it's not fixed yet upstream, so dump_syms won't find much in PEs packing DWARF data.

[acidtonic]

Thanks that was helpful, just to make sure I understand things properly.... this is only an issue on the receiving end and assuming I build the right symbol database, I can be sure the crashdumps produced have the right data to eventually be decoded in the future.

I.E. I can ship the code producing the dumps now and figure out the symbol database later...