This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Import the memory and table for .o files
ClosedPublic

Authored by sunfish on Dec 5 2017, 4:58 PM.

Details

Summary

Instead of having .o files contain linear-memory and function table definitions, use imports. This is more consistent with the stack pointer being imported, and it's consistent with the linker being the one to decide whether linear memory and function table are imported or defined in the linked output. This implements tool-conventions #23.

Edited to remove WASM_DEFAULT_LINEAR_MEMORY and WASM_DEFAULT_FUNCTION_TABLE changes.

Diff Detail

Repository
rL LLVM

Event Timeline

sunfish created this revision.Dec 5 2017, 4:58 PM
ncw added a comment.Dec 6 2017, 12:10 AM

In the GitHub PR, it sounds like you've decided to keep WASM_DATA_SIZE after all, and get rid of WASM_STACK_POINTER/WASM_DEFAULT_LINEAR_MEMORY/WASM_DEFAULT_TABLE in favour of using the symbol names?

sunfish updated this revision to Diff 125805.Dec 6 2017, 1:54 PM
  • Remove the WASM_DEFAULT_LINEAR_MEMORY and WASM_DEFAULT_FUNCTION_TABLE metadata.
  • Update test/MC tests.
sbc100 added a comment.Dec 6 2017, 2:31 PM

Can you update the description.

Code lgtm. But I'm on the fence as to weather this change is really making any useful difference. The don't particularity buy the analogy with __stack_pointer because SP is something that is not know at compile time so is an external dependency of the object file. The memory and table information for each object is internal, and defined internally. It also adds two extra magic symbols which I'm not sure we need (since we can just use table[0] and memory[0]). I know I should have said all that in the issue, and I'm not going to push back against landing this since it seems like a mostly internal detail.

sunfish edited the summary of this revision. (Show Details)Dec 6 2017, 2:45 PM

Can you update the description.

Done.

Code lgtm. But I'm on the fence as to weather this change is really making any useful difference. The don't particularity buy the analogy with __stack_pointer because SP is something that is not know at compile time so is an external dependency of the object file. The memory and table information for each object is internal, and defined internally.

I don't quite understand this. The memory and table for each object is linked with those of the other objects to produce one big memory and table in the output.

It also adds two extra magic symbols which I'm not sure we need (since we can just use table[0] and memory[0]).

I agree that magic symbols are a cost. On the other hand, it doesn't feel right to hard-code index 0. I know that current wasm only supports one table and one memory, and we don't have relocations for rewriting memory indices, but it feels like those could both change in the future.

sbc100 accepted this revision.Dec 6 2017, 3:20 PM
This revision is now accepted and ready to land.Dec 6 2017, 3:20 PM
This revision was automatically updated to reflect the committed changes.
sbc100 added a comment.Dec 6 2017, 5:04 PM

Looks like this requires a corresponding lld change, broke some tests because we were looking the ->tables() on the wasm objects (which is now empty, since they are in the ->imports() now). I'm looking into a few different ways to fix.

sbc100 added a comment.Dec 6 2017, 5:05 PM

Actually if you don't mind I'd like to revert this and prepare a nicer lld-side fix that will work both before and after this change. WDYT?

This can be re-landed one this lld change lands: https://reviews.llvm.org/D40989