diff options
| author | mlugg <mlugg@mlugg.co.uk> | 2025-09-18 12:54:33 +0100 |
|---|---|---|
| committer | mlugg <mlugg@mlugg.co.uk> | 2025-09-30 13:44:55 +0100 |
| commit | 9434bab3134edadae7ae7e575f6b025cafc6a59a (patch) | |
| tree | 141c3ad4208426f1cb4e613ce92a7fd7f57ea044 /lib/std/debug/ElfFile.zig | |
| parent | 23d6381e8b5fb63bc9cba5cc5c78b7946ca4746a (diff) | |
| download | zig-9434bab3134edadae7ae7e575f6b025cafc6a59a.tar.gz zig-9434bab3134edadae7ae7e575f6b025cafc6a59a.zip | |
std: work around crash parsing LLVM PDB
This crash exists on master, and seems to have existed since 2019; I
think it's just very rare and depends on the exact binary generated. In
theory, a stream block should always be a "data" block rather than a FPM
block; the FPMs use blocks `1, 4097, 8193, ...` and `2, 4097, 8194, ...`
respectively. However, I have observed LLVM emitting an otherwise valid
PDB which maps FPM blocks into streams. This is not a bug in
`std.debug.Pdb`, because `llvm-pdbutil` agrees with our stream indices.
I think this is arguably an LLVM bug; however, we don't really lose
anything from just weakening this check. To be fair, MSF doesn't have an
explicit specification, and LLVM's documentation (which is the closest
thing we have) does not explicitly state that FPM blocks cannot be
mapped into streams, so perhaps this is actually valid.
In the rare case that LLVM emits this, previously, stack traces would
have been completely useless; now, stack traces will work okay.
Diffstat (limited to 'lib/std/debug/ElfFile.zig')
0 files changed, 0 insertions, 0 deletions
