This patch fixes a bug where initialization code for .bss segments was
emitted in the memory initialization function even though the .bss
segments were discounted in the datacount section and omitted in the
data section. This was producing invalid binaries due to out-of-bounds
segment indices on the memory.init and data.drop instructions that
were trying to operate on the nonexistent .bss segments.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/test/wasm/data-segments.ll | ||
---|---|---|
65 | There used to be 3 data.drop (FC09) instructions at the end, but now you can see that there are only two, as expected. |
lld/test/wasm/data-segments.ll | ||
---|---|---|
65 | So we doulbly dropping a segment before? | |
lld/wasm/Writer.cpp | ||
832 | So was the crash was happening when there was only a bss segment? And somehow having more than one segment was masking the crash? Should we add a specific test case for that? An example that would have previously caused and invalid binary would be good. I'm stil now clear why we didn't see this is more of our emscripten test cases, |
lld/test/wasm/data-segments.ll | ||
---|---|---|
65 | No, the previous dropping code was "FC0900FC0901FC0902", so it was trying to drop segments 0, 1, and 2. But segment 2 did not exist, so this test was previously producing an invalid binary. | |
lld/wasm/Writer.cpp | ||
832 | The crash was happening when there were any bss segments and the memory was exported, since .bss segments are not isBss if the memory is imported. That's why we never saw this in Emscripten. The existing test case was already invalid, so I don't think we need another one. |
LGTM!
Its shame we don't have a validator here in llvm to checkout the linker output!
There used to be 3 data.drop (FC09) instructions at the end, but now you can see that there are only two, as expected.