-
Notifications
You must be signed in to change notification settings - Fork 37
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
Add Plan 9 support #58
base: main
Are you sure you want to change the base?
Conversation
Thank you for this PR and reporting the memory issue! Does the memory error occur for any WASM binary, or just a specific one? Additional info would be helpful to debug and fix the issue. |
I just pushed a few improvements. Could you please let me know if this still compiles with 9c? I'd also be interested in testing with 9c locally and on CI – is there any way to run it on Linux or macOS? |
Regarding inserting return statements: I guess that is for cases that are actually unreachable, i.e. where |
There's a port to general *nix OSs including MacOS here, but I had to do some editing to get it to work on Linux. Yes, the compilers get mad about unreachable code. I'll test with more wasm files and with the new version tomorrow. |
#61 might fix the memory error. Could you please retry by rebasing on master? |
Will do, got distracted and have been a little bit busy, but I should get it done by the end of the week Edit: My laptop broke, might be a few more days |
This only works on i386, I'm still investigating amd64.
The Plan 9 compiler is slightly strict in a few areas, hence the additional casts and returns.
Currently, w2c2 can also generate code that has missing returns. I haven't fixed this, the generated code needs to have returns manually added when this occurs (as it does with the rust-wasi example).
I left the build system as-is, so you can't just
make
on Plan 9, but you can do it with a custom mkfile or with an rc script or whatever. I figured the makefiles would require too much changes, given that Plan 9's make (and mk) doesn't supportifeq
and whatnot.There appears to be some kind of memory error on amd64, as it aborts in a malloc due to a block being already marked when it should be unmarked. It seems there might be a buffer overflow somewhere. Indeed, when running w2c2 natively instead of using Plan 9's ANSI/POSIX environment (which works fine, it's only wasi that needs APE), the following error message is shown:
I'll look into it further in a bit, 9 has some environmental variables for debugging these kinds of things.
Update: The issue is reported the realloc in arrayEnsureCapacity, so the block metadata gets overwritten sometime between the last calloc and the realloc. Increasing the initial calloc size changes what exactly gets overwritten.