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
Run fpcast-emu before asyncify in the wasm backend #9408
Conversation
…ify whitelist can affect the fpcast helper functions
Following https://groups.google.com/d/msg/emscripten-discuss/YWdLNgCqIjk/54XnVv7vAAAJ I tested the patch. Functions such as I don't experience any difference in the resulting executable's behavior though, possibly those functions aren't crucial in the whitelist. (incidentally these functions are head-truncated in console.trace at 'emu': |
Thanks for testing @Beuc!
|
I don't believe so, because all function names are head-truncated at 'emu' independently of their length. I was thinking maybe some parsing went awry due to the '-'. |
@Beuc Interesting theory, seems plausible. I did a manual test now with a function with |
What does this fix? If |
@AjayP13 If one of these functions is on the stack when unwinding, but the blacklist/whitelist mechanism incorrectless told us to not prepare it for unwinding, then that would be a problem. Otherwise, though, this would just work (these functions would be instrumented just like any other). This PR fixes the ability to whitelist/blacklist these functions, but nothing else. So if you aren't using the whitelist/blacklist, it will have no effect. |
So that the asyncify whitelist can affect the fpcast helper functions.
Regrettable that the fastcomp and upstream paths diverge a little here, but asyncify is totally different between them... when we get rid of fastcomp it'll all be better.