This repository has been archived by the owner on Oct 4, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To provide players with detailed stack traces, we need to embed debug information, including symbol names, into our DLL and EXE files. Recently, we've implemented platform-specific stack resolution techniques: using the
backtrace
library on Linux and Windows APIs on Windows. However, a challenge arises with Windows: it can only resolve symbol names from PDB-based debug information. Our compiler, MinGW, generates debug information in DWARF format (since it's based on GCC), which Windows cannot interpret. As a result, current stack traces on Windows lack meaningful information.We have a few potential solutions to address this issue:
I had little luck with cv2pdb. It turns out, however, that there is already a project which implements the third solution – it's called
dwarfstack
and is available here: https://github.com/ssbssa/dwarfstack/And so, this PR switches the Windows stack resolver from its APIs to this library. Instead of trying to link it statically via Docker's toolchain like we do for SDL and others, I found it easier to use Meson's wrap system. This mechanism lets us use external code just as if it were our own, without having to actually add it to our codebase – even if the upstream repo doesn't use Meson itself. It's really neat IMO.
Example output information from TR2X with a simulated crash in
Text_DrawText
: