{{ message }}
This repository was archived by the owner on Mar 24, 2022. It is now read-only.
Repository navigation
Conversation
i686 rather than i386 because I'd really rather not think about trying to map wasm float semantics to x87...
Member
iximeow
commented
Apr 27, 2020
| #include <ucontext.h> | ||
| #endif | ||
|
|
||
| #include <signal.h> |
Contributor
Author
There was a problem hiding this comment.
This is only present because I was wildly flailing around trying to fix header issues that were caused by fiddling with an include path I shouldn't have. I left it because lucet_types.h references siginfo_t without including signal.h. This isn't an issue because lucet.h includes signal.h before lucet_types.h, but someone using lucet_types.h individually for some reason would be in for a surprise.
... I ought to make this a PR on its own.
Contributor
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First, why
i686?i386has, at best, the x87 FPU for floating point operations. I'm pretty surei686implies processors recent enough to have MMX/SSE, so our floating point stuff needs fewer changes.The ABI details of lining things up for guest execution are certainly incorrect. The primary issue at this point is our dependencies though,
objectbelieves it can't targetI686and Cranelift is missing some legalizations such as 64-bit divides.For object, my suspicion is that just adding a few
I686matches to patterns where it matches forI386should be fine. I've yet to test that though :)With object not being able to emit i686 objects this hasn't gotten to a point where anything, yknow, runs. 😁
While this is a relatively unserious PR, this is about the same shape I suspect other architectures for POSIX-y OSes would look, so replace
i686witharm32oraarch64in your imagination!