LLVM-backend generates COFF with invalid-length strtab entries when dynamically linking zig cc-built C-library (SDL)

[rohlem]

Zig Version

0.11.0-dev.2477+2ee328995

Steps to Reproduce and Observed Behavior

I've not really been able to reduce this to a minimal example, but it's consistently happening to me on a project using some larger libraries (most notably SDL, all built with zig cc, though that shouldn't matter).
However, if I @panic right in main, making calls to these libraries statically unreachable, it stops occurring, so it seems to be linked to overall code size/complexity.

When printing a stack trace, like during a panic, they result in out-of-bounds slicing, which leads to a panicked-during-panic abort.
With debug printing I see that the length read in std.coff.Coff.getStrtab, + the offset, would lead to reading up to f.e. 1903106884 bytes, when the length of self.data is only 16543744 bytes.

I've now also submitted PR #15239, which works around the issue.
It still needs to be investigated where these sections come from, and whether they're actually invalid or just in some other format we would also be interested in supporting.

Expected Behavior

A stack trace instead of panicking.
With #15239 just skipping invalid-length sections, the stack trace still works, so the actually relevant sections don't seem corrupted or anything afaict.

[rohlem]

If it's deemed helpful in investigating this, I can upload the Zig-generated .pdb file that (as far as I understand) should hold these invalid-length sections (currently 1.6 MiB zip-ed).

[kubkon]

If it's deemed helpful in investigating this, I can upload the Zig-generated .pdb file that (as far as I understand) should hold these invalid-length sections (currently 1.6 MiB zip-ed).

It would be more helpful if you could provide a step-by-step repro instructions. Is that a possibility?

[rohlem]

@kubkon Thanks for the quick response!
The issue appears in a large local project with several build.zig scripts that invoke git, CMake, etc. - not quite portable yet due to using some hardcoded absolute paths.
I think it'll be quicker for now to un-hook the nested build scripts, pre-build the dependencies, and reduce the build.zig to only contain the final executable build.
I'll try getting that done and upload it to a GitHub repo by either this evening (12h from now) or the next (36h)!

[rohlem]

@kubkon Okay, a tiny reproduction is now available at https://github.com/rohlem/Zig-invalid-coff-section-length-repro - simply clone it and zig build run.
Turns out it is particularly coupled to SDL (which is linked via DLL) - the issue happens exactly when there are statically-reachable calls to it that aren't optimized out.
The SDL build (contained in the repo) comes from CMake and ninja running zig cc (also version 0.11.0-dev.2477+2ee328995 like in the original post).

[kubkon]

Nice, thanks so much for this! I'll have a look shortly!