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.

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

Fix compilation for target x86_64-unknown-linux-musl. #1180

Merged
merged 8 commits into from
Jan 28, 2020
Merged

Fix compilation for target x86_64-unknown-linux-musl. #1180

merged 8 commits into from
Jan 28, 2020

Conversation

losfair
Copy link
Contributor

@losfair losfair commented Jan 28, 2020

Fixes compilation failure when built for x86_64-unknown-linux-musl.

Fixes #1178 and #1173 .

@losfair
Copy link
Contributor Author

losfair commented Jan 28, 2020

bors try

bors bot added a commit that referenced this pull request Jan 28, 2020
@losfair
Copy link
Contributor Author

losfair commented Jan 28, 2020

bors try-

@losfair
Copy link
Contributor Author

losfair commented Jan 28, 2020

bors try

bors bot added a commit that referenced this pull request Jan 28, 2020
Copy link
Contributor

@MarkMcCaskey MarkMcCaskey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from that 1 comment, it looks good to me!

Some(read_xmm(&fpregs._xmm[15]));
// Skip reading floating point registers when building with musl libc.
// FIXME: Depends on https://github.com/rust-lang/libc/pull/1646
#[cfg(not(target_env = "musl"))]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to handle the other case too? Like

#[cfg(target_env = "musl")]
unimplemented!("blocked on https://github.com/rust-lang/libc/pull/1646");

Or will it work fine as-is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is on the always-taken path for fault handling so panicking here will break things that depend on fault handling, like middlewares. Now all XMM registers will be defaulted to zero if not dumped; do you think it is fine?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I'm not familiar enough to know what the impacts of that are: if you think this leaves the system in a sensible state where execution makes sense then I'm happy with it! Otherwise, I don't think compiling and failing silently is necessarily a step up from panicking or not compiling.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only case where doing so is possibly incorrect is when we take a managed snapshot and then unwind out from WebAssembly code (where floating point state will be lost). This feature is not widely used (yet) and I think it is "cold" enough to ignore for now and defer to after a future upstream fix in musl-libc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, that sounds reasonable to me! We just need to remember to not forget to update this!

@bors
Copy link
Contributor

bors bot commented Jan 28, 2020

try

Build succeeded

@losfair
Copy link
Contributor Author

losfair commented Jan 28, 2020

bors r+

bors bot added a commit that referenced this pull request Jan 28, 2020
1180: Fix compilation for target `x86_64-unknown-linux-musl`. r=losfair a=losfair

Fixes compilation failure when built for `x86_64-unknown-linux-musl`.

- Allows disabling the `wabt` feature to avoid depending on a C++ compiler.
- Disables XMM register dump on fault as a workaround for missing musl libc types (rust-lang/libc#1646).

Fixes #1178 and #1173 .

Co-authored-by: losfair <zhy20000919@hotmail.com>
@bors
Copy link
Contributor

bors bot commented Jan 28, 2020

Build succeeded

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

Successfully merging this pull request may close these issues.

Make wabt an optional dependency
2 participants