Build the Linux dump_syms for Windows with MinGW

[illwieckz]

Build the Linux dump_syms for Windows with MinGW.

I have not tested if it works, I only tested the build for now (on Linux).

How to build:

autoreconf -fi && ./configure --host=x86_64-w64-mingw32 && make -j"$(nproc)" GYP_DEFINES='OS=win'

You then get:

src/tools/linux/dump_syms/dump_syms.exe

It makes possible to symbolize NaCl nexe binaries on Windows.

I guess the same can be done for macOS.

---

Disclaimer: I was assisted by ChatGPT when I was writing and debugging the posix_compat.h file, this was done through a discussion with the bot, by explaining the various shortcomings I was facing in my trial and error attempts. For example when I pushed the branch at first there was still a mistake and the tool didn't do anything despite building successfully. After extensive debugging (I even found a bug unrelated to this patch, I'll report) ChatGPT identified the mistake in the mmap() compatibility wrapper. The bot also suggested API conversion advises and short snippets I had to adapt in the making of those wrappers. The chat bot didn't have access to the repository (neither read, neither write) and only answered my questions based on my descriptions and its general knowledge of upstream breakpad and APIs from Linux, Windows and MinGW. Once the patch was ready I pasted the diff in the bot conversation and the chat bot identified some shortcomings like redundant things I cleaned-up.

[illwieckz]

When running it on Wine I get:

Failed to write symbol file.

So maybe it fails on some /dev/stdout equivalent for Windows.

[illwieckz]

It now works. It was a mistake with flags in the mmap() wrapper.

When generating symbol files with the Linux native dump_syms or the Windows dump_syms_elf built with MinGW and running on Linux, they are the same, except the end line (DOS or Unix style). When converting symbol files with dos2unix the files are identical bit to bit. I tested by running the symbolizers on the Linux daemon engine client binary.

[illwieckz]

This test looks useless! 😅️

[illwieckz]

Fixed.

[illwieckz]

So, after having rebased the code over:

• dwarf2reader: support NaCl Saigo CFA pseudo-register -2 #19

I symbolized a cgame-amd64.nexe built with Saigo using the MinGW-build dump_syms_elf running on Wine and it produced the exact same symbol file as the native Linux dump_syms (once the file produced by the Windows binary is converted to linux line ending it's the same).

[illwieckz]

Actually merging this would make far easier to solve some merge conflicts from:

• Merging upstream? (2026-07) #21

Because then we can revert 4678e20:

    Disable DwpReader for MinGW
    
    elf_reader.cc uses mmap(), which isn't available
    
    Perhaps we could change to using MmapWrapper(), which I've already fixed for
    Windows, but this code isn't doing anything for us anyhow

So even if “this code isn't doing anything for us anyhow”, the specialization of the code is generating annoying conflicts.

[illwieckz]

Anyway, since that's just a copy of the Linux dump_syms (without stabs), we may just enable stabs for it and don't duplicate the Linux dump_syms. Then we would have to rename Windows dump_syms to something like dump_syms_pecoff because dump_syms would be the ELF one. We may also rename everything to avoid any confusion (only rename the build artifact to not introduce merge conflicts):

• dump_syms_elf
• dump_syms_macho
• dump_syms_pdb
• dump_syms_dwarf

[illwieckz]

MinGW is now building linux_dump/syms/dump_syms.exe with nothing disabled compared to the Linux build (so that includes stab support) The _SOURCES is duplicated because of the way the Makefile.amis written. Upstream breakpad reworked the Makefile.am in a way we will be able to deduplicate that later.

[illwieckz]

Today I learnt that we cannot even build Windows' dump_syms with MinGW…