Skip to content

EMULATED_FUNCTION_POINTERS=1 issue with EH and functions returning int64 #7399

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

Closed
vargaz opened this issue Oct 27, 2018 · 8 comments
Closed

Comments

@vargaz
Copy link
Contributor

vargaz commented Oct 27, 2018

Testcase:

#include <cstdio>
#include <cstdint>

int64_t foo (void)
{
	return 5;
}

typedef int64_t (Func) (void);

Func *bar;

int main (void)
{
	bar = foo;

	try {
		printf ("%d\n", bar ());
	} catch (int i) {
	}
}

Compile with:

emsdk_env.sh && emcc -g  -s DISABLE_EXCEPTION_CATCHING=0  -s EMULATED_FUNCTION_POINTERS=1 -s ALIASING_FUNCTION_POINTERS=0 -s EXIT_RUNTIME=1 -s WASM=1 -s BINARYEN=1 foo.cpp

Expected result:

5

Actual result:

exception thrown: TypeError: cannot pass i64 to or from JS
[email protected]:2221:10
[email protected]:2211:12
[email protected] line 1656 > WebAssembly.instantiate:wasm-function[104]:0xbc16
[email protected] line 1656 > WebAssembly.instantiate:wasm-function[29]:0x5a2
[email protected]:2446:10
@vargaz vargaz changed the title EMULATED_FUNCTION_POINTERS=1 issue with functions returning int64 EMULATED_FUNCTION_POINTERS=1 issue with EH and functions returning int64 Oct 27, 2018
@kripken
Copy link
Member

kripken commented Oct 30, 2018

I can confirm this issue. What happens is we need to do a call to a function type that is not valid in JS, so we need to legalize it. We legalize imports and exports properly, but the invoke/dynCall logic is somewhat special and I guess we need to fix something there.

Also confirming that this should only affect code using exceptions or setjmp, where an invoke ends up necessary to a function type containing an i64.

@aardappel
Copy link
Collaborator

Can confirm this issue as well. In my own code I can work around it by marking functions like foo in the example above with noexcept, but it also happens when calling functions in SDL that use 64-bit arguments, like https://wiki.libsdl.org/SDL_RWseek

vargaz added a commit to vargaz/emscripten that referenced this issue Nov 19, 2018
…d function pointer mode correctly by

calling the ftCall_helper_<sig> functions exported by the wasm mode.

Part of the fix for:
emscripten-core#7399
@vargaz
Copy link
Contributor Author

vargaz commented Nov 19, 2018

Submitted two 2 PRs to fastcomp/emscripten with a possible fix.

vargaz added a commit to vargaz/emscripten that referenced this issue Dec 13, 2018
vargaz added a commit to vargaz/mono that referenced this issue Dec 14, 2018
luhenry pushed a commit to mono/mono that referenced this issue Dec 18, 2018
* [wasm] Add the fix for emscripten-core/emscripten#7399 as a patch for emscripten.

* [wasm] Factor out some flags from the makefile targets.

* [wasm] Enable EMULATED_FUNCTION_POINTERS.
@jaykrell
Copy link

The sample doesn't look legal, but that may be besides the point.
i.e. it is passing int64_t to %d (unless int==int64_t which is possible but unlikely).

@AlexAltea
Copy link

AlexAltea commented Feb 19, 2019

Could anyone please suggest a temporary workaround for this issue?

I'm in a scenario where both -s EMULATED_FUNCTION_POINTERS=1 and setjmp/longjmp are necessary, and this causes a direct call to be transformed into a $legalfunc$invoke_iij call (see #8119).

Unfortunately, my codebase is plain C, and I'm unable to set C++11 attributes such as noexcept as @aardappel suggested.

@kripken
Copy link
Member

kripken commented Feb 19, 2019

I think this is almost fixed - we legalize invokes now, and #8065 should fix emulated function pointers as well - may be interesting to test your code with that PR.

@vargaz
Copy link
Contributor Author

vargaz commented Feb 22, 2019

The testcase above seems to work now.

@vargaz
Copy link
Contributor Author

vargaz commented Feb 23, 2019

This is now fixed. Thanks.

@vargaz vargaz closed this as completed Feb 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants