-
Notifications
You must be signed in to change notification settings - Fork 165
support cross-compilation #387
Comments
Seems like a reasonable thing to support, and it shouldn't be much trouble. lucetc determines the target triple of the host machine, which will in turn determine whether the object file is output for Linux or Mac OS. How do you feel about sending a PR that adds a command line option to specify a target triple which overrides this default? However, lucet-runtime doesn't actually work correctly on Mac OS for wasm programs that trap - there are some problems with the signal handler implementation, which ends up working differently than Linux. We weren't able to put more time into fixing it. If this is something you're depending on for Mac OS, we could point you in the right direction towards fixing it. |
We don't currently enable the signal handler with lucet (maybe we should). Can you point out the problematic code and/or the issues with it? |
The signal handler is how Lucet handles traps in wasm code, so its very important to the safety story. Cranelift translates many faults (some bounds checks, icall type mismatch, many others) into code that executes Since Lucet executes Wasm code on a separate stack, the signal handler takes care of setting instance state to indicate the trap that occurred, and then switches the stack back to the originating host stack. The stack switching (as part of signal handler return) seems to be what is broken on Mac OS. We can have a zoom call if you need more context on this. |
Also note that unless you've modified the internals of |
This doesn't seem to be supported based on
--help
and a quick browse through the code. It's entirely possible I'm missing something, though!Firefox, at least, would really like this for Linux -> OS X cross builds, as well as several other cases.
The text was updated successfully, but these errors were encountered: