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.

Sign up for GitHub

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

Jump to bottom

WASI-SDK 25 call_indrect doesn't work on Darwin #3977

Open
woodsmc opened this issue Dec 19, 2024 · 4 comments
Open

WASI-SDK 25 call_indrect doesn't work on Darwin #3977

woodsmc opened this issue Dec 19, 2024 · 4 comments

Comments

@woodsmc
Copy link
Contributor

woodsmc commented Dec 19, 2024

Thanks for filing a bug or defect report! Please fill out the TODOs below.

Subject of the issue

WASI SDK 25 generates a call indirect which uses a ref type format. It doesn't parse correctly on the default build of iwasm for Darwin. Executing the generated wasm with the default iwasm for Darwin results in : ``WASM module load failed: zero byte expected`

Test case

Upload the related wasm file, wast file or the source files if you can.

#define WASM_EXPORT(A) __attribute__((export_name(A)))

typedef int(*TFunction)(int);

int function(int x) {
	x *= 25;
	return x;
}

int work(int x, TFunction ptr) {
	return (*ptr)(x);
}

WASM_EXPORT("test") int test(int x) {
	return work(x, &function);
}

Compile this with wasi-sdk-25 and attempt to execute with iwasm results in an error message - ``WASM module load failed: zero byte expected`

Your environment

  • Host OS: MACOS
  • WAMR version, platform, cpu architecture, running mode, etc.

Steps to reproduce

Tell us how to reproduce this bug or defect.

Build the code above with wasi-sdk-25, attempt to run with default iwasm on darwin. Receive error message as below

iwasm -f test ./indirect.wasm 25

And the error message ``WASM module load failed: zero byte expected` is displayed.

Expected behavior

Tell us what should happen: The function should execute

Actual behavior

Tell us what happens instead: WAMR displays error message instead.

Extra Info

Anything else you'd like to add?
@woodsmc woodsmc mentioned this issue Dec 19, 2024
Merged
@woodsmc
Copy link
Contributor Author

woodsmc commented Dec 19, 2024

I think turning on reference types resolves this issue. This PR changes the default CMake file for Darwin to do this. #3978

It appeared to be turned on by default on the linux build at the moment, just not on Darwin.

@loganek
Copy link
Collaborator

loganek commented Dec 20, 2024

Hi @woodsmc I think it's reasonable to enable ref types by default. Having said that, I think we could do a better job in terms of error reporting and have clear message when iwasm was compiled with ref types disabled but the binary was compiled with ref types enabled. I can make the change once I'm back from holiday (January next year) so let's keep the issue open until the error handling is improved so I don't forget about it :)

@woodsmc
Copy link
Contributor Author

woodsmc commented Dec 20, 2024

@loganek That's a great idea, if I get the chance over the holidays, I might try to add that concept to the PR - fir this specific case anyway. Or - are you thinking of something more compiler flags, error specific. - Generating a table of the compiled flag options, and using this to allow the WAMR runtime to report how it's compiled, and use the same structure to aid with error condition diagnosis and messaging to the user ?

@loganek
Copy link
Collaborator

loganek commented Dec 20, 2024

@woodsmc AFAIK we can get that information (whether ref types are being used in the wasm binary) from the type section - if that's detected, and WAMR was compiled with ref types disabled, we show an error and stop loading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@loganek @woodsmc