Support FreeBSD #419
Support FreeBSD #419
Conversation
|
This is rad! I'm glad to see how small the diff is too :) I suspect the linker error you're seeing is us doing something funny in writing relocations. I don't recall off the top of my head what segment these would end up in, but if for some reason it was readonly I think that would make the error you see. The Do you know how we might set up FreeBSD testing using GitHub CI? If we're working on FreeBSD it would be good to ensure we don't break that in the future, though it may end up similar to macos where we can't guarantee full functionality (see also: our signal handler still misbehaves on macos) |
|
Thank you for working on this! With regard to our out-of-date wasi-common dependency- @kubkon and I have been working on some major renovations to the library, using a new code generator https://github.com/kubkon/wiggle. This work will eliminate a bunch of duplicated code and give us a good path to support future snapshots. I've held off on updating wasi-common until those changes are made, because most of the changes needed to support the current version would change yet again. I expect all of that to land before the end of the month. |
Cool, I'll wait for that then.
Not with GitHub Actions right now, but Cirrus (example) and builds.sr.ht are the two well known options.
That's fine. My primary use case so far would be trying to enable Firefox's rlbox sandboxing, which they do use on macOS I think. |
|
Thanks for the pointers on CI. The Cirrus setup looks reasonable. I'll look into that sometime when I get a chance. It turns out that Firefox's rlbox uses a different signal handler than the one that |
|
Nudging this: can you retry Lucet's tests with the changes from If you get to it soon, I expect you'll see test failures in the |
|
Nah, still PoisonErrors: runtime test results
These tests aren't running, I couldn't figure out how to make them run.. |
|
Drat. The
|
Oh. Well that's the same thing as I fixed in |
|
Now that #437 has landed, we expect things to be a bit better. Do you mind pulling those changes in? |
|
Okay, I see the So now, the only dependencies are
And the only test failures are in `LD=ld.lld10 WASI_SDK=/usr/local cargo test` run results |
|
Fantastic! We actually don't pass all wasm spectests on linux or macos either, mostly because we don't support importing wasm globals for the time being, so That said, if memory serves I think we only fail five suites on those platforms, where Probably worth checking to see if this varies from other platforms. I think we really just have to get CI squared away at this point, though! |
|
|
|
@myfreeweb You are such an awesome steward of the ecosystem. :) Thanks for all this, so much. |
|
hmm, how am I not hitting the "stack size must be a multiple of host page size" error when testing, when (hit that with the rlbox/mozilla fork of lucet, when running firefox) Is that check correct? Why does it matter that stack size is a multiple of page size? |
|
That's a good question. My first suspicion would be that rlbox might be setting a custom stack size derived from the platform, but Can you collect As for why it matters, |
|
Well, if debug_assertions are on by default (I didn't touch anything related to that), here it was
that is what failed in rlbox I think — I mentioned the "stack size must be a multiple of host page size" string specifically :) After commenting that assertion out, it barely works in Firefox: ogg mostly works but sometimes crashes, graphite instantly crashes. One backtrace showed
The manpage hints at something like that:
Must be some historical weirdness, on arm and arm64 |
Great! I'd totally glazed over the
|
|
This PR was closed as a byproduct of deleting the branch named |
|
wooooo required libc PR is in \o/ Since this also needs newer |
|
Thanks! #553 is pending some of the integration passing some downstream tests on our internal stuff, and I took some vacation since starting it, should be getting it in within a day or two. |
|
Since #553 was closed, can we from draft to ready for review? |
Linux is not strict on this, but e.g. FreeBSD is.
On FreeBSD/amd64, SIGSTKSZ == MINSIGSTKSZ(4 * 512) + 32768 == 34816. This is not a multiple of the 4k page size, which is required, so use the custom size. Plus, rewrite the choice using cfg_if, as manual cfgs are getting unwieldy.
Finally includes FreeBSD/amd64 mcontext/ucontext
|
Rebased, undrafted |
|
Undrafting got me to notice
again and to follow up there too: #563 is an issue tracking linkage with |
|
@iximeow it is resolved, haven't needed any extra flags for a while. |
|
ping |
|
Sorry, this fell off our radar. CircleCI is messed up for forks, I forget the root cause anymore but I rebased and pushed this to #577 to see if we can get it to go green. We haven't had any time to get CI testing for the freebsd target working - Unfortunately, our team doesn't have bandwidth to support additional platforms in general. If someone can provide a config to run CI in freebsd on either Github CI or CircleCI, we'd welcome it, but at this time we aren't keen to add yet another CI provider. I am willing to merge this support without CI and rely on freebsd contributors to file PRs to fix anything that inadvertently gets broken. |
|
Yeah, I'm fine with that, I basically never expect CI from anyone. |
|
Merged as #577. Thank you for your work on this! |
Hi, this is sort of a work-in-progress but I have Lucet working on FreeBSD/amd64. Not many changes here but
wasi-commonneeds to be updated somehow…wasi-common/yanixrequires fixes — wasi-common/yanix: fix FreeBSD support wasmtime#756 for the upstream version, but lucet uses an older one (0.7.0) — I have a backport for that locally, but it would be better if lucet could upgrade-z notext, otherwise:ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output— ?? Should I just usenotextin the default flags, or is there some very well hidden settings for the output to be fully position-independent?wasi-libcandcompiler-rtas an OS package.WASI_SDK=/usr/localseems to work fine with that.PoisonErrors are happening in tests o_0 but real examples work fine.Test failures (PoisonError)