aboutsummaryrefslogtreecommitdiff
path: root/lib/std/debug/ElfFile.zig
diff options
context:
space:
mode:
authormlugg <mlugg@mlugg.co.uk>2025-09-18 12:54:33 +0100
committermlugg <mlugg@mlugg.co.uk>2025-09-30 13:44:55 +0100
commit9434bab3134edadae7ae7e575f6b025cafc6a59a (patch)
tree141c3ad4208426f1cb4e613ce92a7fd7f57ea044 /lib/std/debug/ElfFile.zig
parent23d6381e8b5fb63bc9cba5cc5c78b7946ca4746a (diff)
downloadzig-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