Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix initial value of sbrk(0) #9553

Merged
merged 4 commits into from
Oct 2, 2019
Merged

Fix initial value of sbrk(0) #9553

merged 4 commits into from
Oct 2, 2019

Conversation

kripken
Copy link
Member

@kripken kripken commented Sep 30, 2019

Emscripten side of WebAssembly/binaryen#2366 (that must roll first) , this tells binaryen to set the value in the wasm binary, which fixes standalone wasm module's sbrk() usage (as normally we set this is JS).

This also disables eval-ctors for the wasm backend, see #9527 , which made an incorrect assumption about the sbrk initial location - JS may modify it during startup, so we can't assume it's constant. This affects only -Oz so it's probably not many users.

After this PR we should be correct in both standalone and non-standalone modes, and later we can look into re-enabling eval-ctors.

@kripken kripken requested a review from tlively October 2, 2019 16:29
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, but I'm a little shaky on the context, specifically what assumptions are made about the sbrk pointer and how it is used in the various modes.

@kripken
Copy link
Member Author

kripken commented Oct 2, 2019

The sbrk pointer is basically the location in memory where we store the program brk. We normally set it up in JS, as we allow JS to allocate during startup. Then when wasm runs it continues with that value. But in standalone mode, there is no JS, so we use the new binaryen flag to hardcode it in the wasm binary.

That interaction between JS and wasm is also why the ctor evaller is not valid; JS can modify the value but the ctor evaller assumes what it sees in memory is what will be there at runtime.

@kripken kripken merged commit 38bdf2e into incoming Oct 2, 2019
@kripken kripken deleted the sbrk-val branch October 2, 2019 17:18
belraquib pushed a commit to belraquib/emscripten that referenced this pull request Dec 23, 2020
Emscripten side of WebAssembly/binaryen#2366 (that must roll first), this tells
binaryen to set the value in the wasm binary, which fixes standalone wasm
module's sbrk() usage (as normally we set this is JS).

This also disables eval-ctors for the wasm backend, see emscripten-core#9527 , which made an
incorrect assumption about the sbrk initial location - JS may modify it during
startup, so we can't assume it's constant. This affects only -Oz so it's
probably not many users.

After this PR we should be correct in both standalone and non-standalone modes,
and later we can look into re-enabling eval-ctors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants