This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Properly calculate function body offset, and write I32 values.
ClosedPublic

Authored by yurydelendik on May 22 2018, 9:35 AM.

Diff Detail

Repository
rLLD LLVM Linker

Event Timeline

yurydelendik created this revision.May 22 2018, 9:35 AM
sbc100 accepted this revision.May 22 2018, 10:07 AM

Does these fix the issues you had with you large binary?

This revision is now accepted and ready to land.May 22 2018, 10:07 AM

Yes, is does. Large binary demo I have now runs without issue.

This revision was automatically updated to reflect the committed changes.
ruiu added a subscriber: ruiu.May 22 2018, 11:00 AM

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.

ruiu added a comment.May 22 2018, 11:19 AM

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.

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.

ruiu added a comment.May 22 2018, 1:41 PM

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?

ruiu added a comment.May 22 2018, 2:00 PM

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.