Support for Windows applications compiled with MSYS2+Mingw-w64 GCC

[SlySven]

Problem Statement

The F.O.S.S. Mudlet MUD Client has recently adopted Sentry as a means to marshal information about problems with our product. We compile its Windows builds in a MSYS2+Mingw-w64 environment - as such we've been using a GCC compiler which is not (AFAICT) capable of generating "debug" information in the Windows .pdb format. I am aware that we could switch to the LLVM clang alternative and get the wanted symbols by providing -g -gcodeview as compiler options. However the upstream's debug symbols for the packages that we link to are provided only as separate .debug files - so that automatically prevents issues in code that we do not author from being properly handled by Sentry.

My apologies for not bringing this up as a Discussion as your contribution guide suggests but I could not see any discussion where this would fit.

Solution Brainstorm

Is there any way that Sentry could have the option to handle GCC .debug debug symbol files for Windows applications in the same manner that it does for GNU/Linux ones?

Product Area

Unknown

[linear]

ENG-6108

[getsantry]

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

[getsantry]

Routing to @getsentry/product-owners-ingestion-and-filtering for triage ⏲️

[Dav1dde]

I assume these .debug files are just DWARF? So the problem might be that we need to allow/expect DWARF for Windows binaries.

Do you by any chance can link to some of these files?

[Dav1dde]

@supervacuus I see you have some context for MingW judging by this issue, is our best way forward just to recommend llvm/clang or is it reasonable to support what gcc outputs?

[supervacuus]

Hi @Dav1dde.

is our best way forward just to recommend llvm/clang or is it reasonable to support what gcc outputs?

We already recommend using LLVM-MinGW in the Native SDK because of its PDB support. It is also essential for an answer to your question to consider that MinGW support is almost entirely community-based. There is no official support in the Native SDK and certainly no "roadmap" items. I also know that GCC-based MinGW experimented with PDB support, but I haven't recently investigated it. It's also not really relevant for a use case where upstream libraries provide their debug information in DWARF.

The LLVM-MinGW solution of offering PDB as an output artifact is hugely helpful, because PDBs are the native debug format for Windows (as in: there is broader tooling support, not even considering Sentry). So, if you have a PE and a PDB, you're set. This is not at all true for the PE+DWARF combo. There are a couple of tools that try to convert DWARF to PDB after the fact, but in my experience, they are very unreliable and poorly maintained/documented.

Coming back to Sentry:

Right now, the first barrier is that sentry-cli doesn't even treat DWARF as debug information for a PE. That is where most users fail.

Even if it did, it is unclear to me how much effort it would be in "processing" to use DWARF for PE binaries, and whether this is primarily a problem of association (given that we already support PE and DWARF independently and have IRs for stack-walking and symbolication), or whether this requires a new processing element that involves conversion between the formats. The latter would be likely much more involved.

This is where I would redirect the question to @loewenheim or someone else deeply involved with current developments in "processing".