- Gets function size field from right location
- Writes I32 values during compression
Details
- Reviewers
sbc100 - Commits
- rG65a91288fcbf: [WebAssembly] Fix two bugs in LEB compression: properly calculate function body…
rL333002: [WebAssembly] Fix two bugs in LEB compression: properly calculate function body…
rLLD333002: [WebAssembly] Fix two bugs in LEB compression: properly calculate function body…
Diff Detail
- Repository
- rLLD LLVM Linker
- Build Status
Buildable 18459 Build 18459: arc lint + arc unit
Event Timeline
I think a patch like this needs a test to demonstrate that a patch actually fixes an issue.
The test at D46416 tests this -- it was a luck that the unset buffer (Buf) contains mostly right values.
Was the test in that change was failing on your machine? If it passed (if it happened to work), you still need to change the test, so that it fails without this patch and passes with this patch.
There are two parts to this change. The write32le() is there for correctness but really could be replaces with llvm_unreachable since this relocation type should never occur in the code section today.
The second fix which was to pass the correct argument to decodeULEB128() is hard to write a test for. It a used of uninitialized memory which should really have been caught be msan (do we run that on any bots?, perhaps not with wasm enabled?). Its hard to write a failing test because of this and I'm not sure unit tests are the best way to check these types of failures.
I'm not sure if I fully understand the problem, but don't you have a binary that didn't link correctly without this patch, no? I thought that you could reduce it to create a test.
As to the code that could be llvm_unreacahble, I think it should be llvm_unreacahble. If some path is not expected to run, we shouldn't write code for it.
In term of the uninitialized memory issue, let me see if I can restate so that we can come to the same understanding.
The code is calling decodeULEB128(Buf, &Count); to decode at LEB stored in Buf but its ignoring the result. All it cares about is the number of bytes consumed (Count). As it happens in the original code Buf is pointing to uninitialized memory. It also happens that in the test cases we have Count is always expected to be 1 (since the size of the functions we are testing with are < 127 so it only take a one byte LEB to store their length). So as long as the uninitialized data bytes is between 1 and 127 then the tests will pass. We could construct a test with larger function body which would probably fail.. but it really depends on the uninitialized data so its only likely to fail :) But we should probably as that test anyway I guess?
Yes, I think you should write a test with a large function to exercise this code. Also, I don't think the buffer is an initialized memory. It is pointing to an output mmap'ed file, and the mmap'ed file is filled with 0.