Remove memory/table information from emscripten_metadata #12189
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The emscripten metadata section was originally added back in #7815. @rianhunter I'm hoping that these particular pieces are data are no longer needed. emscripten has moved a lot of this stuff into internal implementation details on the wasm side so I'm hoping that exporting it is no longer needed in order to run an emscripten-built module. What do you think? Could you confirm this for me? |
sbc100
force-pushed
the
cleanup_emscripten_metadata
branch
from
a1514af
to
fc381e8
Compare
|
For example, implementing malloc or sbrk outside of the wasm module previously required this information, but those functions are now always part of the module itself. |
sbc100
changed the title
sbc100
force-pushed
the
cleanup_emscripten_metadata
branch
from
fc381e8
to
4d8b58b
Compare
|
See #12231 |
kripken
reviewed
Sep 15, 2020
| @@ -19,7 +18,7 @@ | |||
| # NB: major version 0 implies no compatibility | |||
| # NB: when changing the metadata format, we should only append new fields, not | |||
| # reorder, modify, or remove existing ones. | |||
| EMSCRIPTEN_METADATA_MAJOR, EMSCRIPTEN_METADATA_MINOR = (0, 3) | |||
| EMSCRIPTEN_METADATA_MAJOR, EMSCRIPTEN_METADATA_MINOR = (1, 0) | |||
There was a problem hiding this comment.
1 as the major version indicates stability (see line 19/18) - probably we don't want that?
sbc100
force-pushed
the
cleanup_emscripten_metadata
branch
from
4d8b58b
to
1a6c680
Compare
We are moving away from the world where the memory layout if decided by the python driver code and towards a world where the wasm-ld decides the final layout. For relocatable module (SIDE_MODULE and MAIN_MODULE) the size and alignment of memory and table segments is already encoded in the `dylink` sections. For non-relocatable modules I don't think this information is needed by the embedded as they can simply look at the requirements on the table and memory that a given module imports. In general symbols like `__global_base` or `__data_end` and `__heap_base` are details we don't export by default but can be explictly exported if needed.
sbc100
force-pushed
the
cleanup_emscripten_metadata
branch
from
1a6c680
to
0c5e0fb
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are moving away from the world where the memory layout is
determined by the python driver code and towards a world where
the wasm-ld decides the final layout.
For relocatable module (SIDE_MODULE and MAIN_MODULE) the size
and alignment of memory and table segments is already encoded
in the
dylinksections.For non-relocatable modules I don't think this information is
needed by the embedder anymore.
Symbols like
__global_baseor__data_endand__heap_basearedetails we don't export by default but can be explicitly exported if needed.
This is part of an effort to completely remove DYNAMIC_BASE.