Skip to content
This repository has been archived by the owner on Mar 24, 2022. It is now read-only.

support cross-compilation #387

Open
froydnj opened this issue Jan 10, 2020 · 4 comments
Open

support cross-compilation #387

froydnj opened this issue Jan 10, 2020 · 4 comments

Comments

@froydnj
Copy link
Contributor

froydnj commented Jan 10, 2020

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.

@pchickey
Copy link
Contributor

pchickey commented Jan 10, 2020

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.

@froydnj
Copy link
Contributor Author

froydnj commented Jan 16, 2020

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?

@pchickey
Copy link
Contributor

pchickey commented Jan 16, 2020

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 ud2 instruction to trigger a SIGILL. Other memory access faults are expected to land on non-read-writable pages and are expected to trigger a SIGSEGV.

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.

@acfoltzer
Copy link
Contributor

We don't currently enable the signal handler with lucet (maybe we should).

Also note that unless you've modified the internals of lucet-runtime to explicitly remove the signal handler, it will be automatically installed when a Lucet instance first runs, and uninstalled when there are no longer any running instances. This handler is installed whether or not you've set the user-definable signal handler, which is used to add custom behavior to the signal handler.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants