Flesh out emscripten metadata #8519
Conversation
DYNAMICTOP_PTR and tempDoublePtr are no longer deterministically computable from STATIC_BUMP. Also GLOBAL_BASE is not always 1024. Pass these through emscripten metadata for third-party runtimes that consume Emscripten-generated WASM binaries.
tools/shared.py
Outdated
| # NB: more data can be appended here as long as you increase | ||
| # the EMSCRIPTEN_METADATA_MINOR | ||
|
|
||
| b'' |
There was a problem hiding this comment.
Just for symmetry purposes with the preceding lines (each ending with +). Fine to take out at the small expense of potentially incurring unnecessary line diffs in future edits of this function.
There was a problem hiding this comment.
Ah I see. How about using contents = b''.join(... , then you can use trailing commas on each line?
There was a problem hiding this comment.
I could do that but then I'd have to change more lines of code :) (see this comment for past comment on keeping code style consistent: #7815 (comment)) I have no problem doing it if you really think it's worth it.
There was a problem hiding this comment.
OK, but if you are going to leave the multiline + but in that case I would drop the extra b''.
Also, is there a reason why echo the lines above is separated by an empty line? This is odd, especially since its single expression.
tools/shared.py
Outdated
| m = re.search(r"DYNAMIC_BASE\s+=\s+(\d+)", js) | ||
| dynamic_base = int(m.group(1)) | ||
| m = re.search(r"DYNAMICTOP_PTR\s+=\s+(\d+)", js) | ||
| dynamictop_ptr = int(m.group(1)) |
There was a problem hiding this comment.
This seems strangely convoluted to read back in the file we just generated.
There was a problem hiding this comment.
It would require more extensive changes to force the JS compiler to use a value for DYNAMICTOP_PTR that would be chosen by Python. Right now it's automatically allocated by makeStaticAlloc(). I thought the method of parsing the JS was acceptable since it was done in earlier incarnations of this function.
tools/shared.py
Outdated
|
|
||
| WebAssembly.lebify(dynamictop_ptr) + | ||
|
|
||
| WebAssembly.lebify(tempdouble_ptr) + |
There was a problem hiding this comment.
Would it make more sense to export these things as globals from the wasm file?
If we are going to make this an ABI can we document to exact meaning on each of these things?
Do all these make sense with both fastcomp and the llvm backend?
There was a problem hiding this comment.
The reason they are in a different metadata section is that they must be used to properly parameterize the Emscripten runtime before the WASM can be successfully instantiated. (There is a circular dependence).
Medium term this will be documented exactly. I still don't consider it stable enough to document, which is partly the reason it isn't emitted automatically and requires "-s EMIT_EMSCRIPTEN_METADATA=1" to opt in. There is some initial documentation for developers here https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone#jswasm-abi
At least as far as emulating the JS runtime, tempDoublePtr, DYNAMICTOP_PTR, and DYNAMIC_BASE makes sense with the LLVM backend. It wouldn't be possible for the host to implement sbrk() and copyTempDouble() without those parameters. global_base does not seem to be needed by LLVM generated WASM files (in asmjs/binaryen it's imported as __memory_base). I haven't yet successfully run LLVM generated WASM binaries but to be honest I anticipate more changes at that time.
There was a problem hiding this comment.
I'm OK with landing this now, as long as we can iterate on this, change it, and hopefully simplify it in the future. I wouldn't want to be locked in the ad-hoc conventions we currently have without a more formal spec.
There was a problem hiding this comment.
+1, Major version on this metadata section is still 0, so it's still explicitly not supported and not guaranteed to be in any specific format.
| @@ -2979,8 +2979,20 @@ def delebify(buf, offset): | |||
|
|
|||
| @staticmethod | |||
| def add_emscripten_metadata(js_file, wasm_file): | |||
| mem_size = Settings.STATIC_BUMP | |||
| WASM_PAGE_SIZE = 65536 | |||
There was a problem hiding this comment.
so STATIC_BUMP is no longer needed?
There was a problem hiding this comment.
STATIC_BUMP was being used to compute DYNAMICTOP_PTR and tempDoublePtr but since those are now not derived from STATIC_BUMP it's no longer necessary to store that.
| mem_size = Settings.STATIC_BUMP | ||
| WASM_PAGE_SIZE = 65536 | ||
|
|
||
| mem_size = Settings.TOTAL_MEMORY // WASM_PAGE_SIZE |
There was a problem hiding this comment.
Doesn't // do the wrong thing here and round down? I guess TOTAL_MEMORY is already guaranteed to be a multiple so probably fine.
There was a problem hiding this comment.
Yeah, the intent is to make sure mem_size is an integer. I could have done int(TOTAL_MEMORY / WASM_PAGE_SIZE) but this seemed better.
DYNAMICTOP_PTR and tempDoublePtr are no longer deterministically computable from STATIC_BUMP. Also GLOBAL_BASE is not always 1024. Pass these through emscripten metadata for third-party runtimes that consume Emscripten-generated WASM binaries.
This reverts commit c25f8bc.
This reverts commit c25f8bc.
DYNAMICTOP_PTR and tempDoublePtr are no longer deterministically computable from STATIC_BUMP. Also GLOBAL_BASE is not always 1024. Pass these through emscripten metadata for third-party runtimes that consume Emscripten-generated WASM binaries.
DYNAMICTOP_PTR and tempDoublePtr are no longer guaranteed to be
computable from STATIC_BUMP. Also GLOBAL_BASE is not always 1024.
Pass these through emscripten metadata for third-party runtimes
that consume Emscripten-generated WASM binaries.