-
Notifications
You must be signed in to change notification settings - Fork 1.1k
FreeBSD: ucontext/mcontext, aarch64 fixes, librt linking, etc #1630
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
Conversation
valpackett
commented
Dec 30, 2019
- adds mcontext/ucontext structs, needed for lucet
- on amd64 and aarch64 because that's what I have… (well I technically have armv7 but it's not set up properly)
- fixes all tests on aarch64 (because I wanted to test mcontext)
- Add u128/i128 == __uint128_t/__int128_t gnzlbg/ctest#89 necessary to handle u128
- I haven't noticed [Draft] Add __int128 to unix targets #1414… hmm?? is that the better approach?
- Add u128/i128 == __uint128_t/__int128_t gnzlbg/ctest#89 necessary to handle u128
r? @gnzlbg (rust_highfive has picked a reviewer for you, use r? to override) |
d65b0da
to
2481232
Compare
2481232
to
8ea285d
Compare
8ea285d
to
67e42ab
Compare
ping. this is really needed for Lucet, which is in pretty good shape now. we could leave FreeBSD/aarch64 untested because the tests currently don't work in master anyway. or I could split the aarch64 mcontext into a separate PR that would wait for proper 128 bit support in tests or whatever is needed. |
67e42ab
to
fd1a77d
Compare
Sorry for the delay, I'll check it later. |
Hm, CI fails: nightly x86_64-unknown-freebsd-10. Also needs to fix style issues. |
fd1a77d
to
c86b93b
Compare
Added Now docs for i686 fail to generate??
but.. I see there's plenty of |
3867299
to
009b1e8
Compare
Now all CI failures seem unrelated |
ping |
Oh, sorry for the delay! Unfortunately, the build log has been gone, re-triggering CI. |
8531a0c
to
af0442b
Compare
Yes, that would be very good. |
CI still fails with importing and |
That looks like some really ancient rustcs not being able to apply I guess I can move the whole |
af0442b
to
6c68110
Compare
@@ -78,6 +80,16 @@ s_no_extra_traits! { | |||
pub xmm_reg: [[u8; 16]; 8], | |||
pub xmm_pad: [u8; 224], | |||
} | |||
|
|||
#[cfg_attr(feature = "extra_traits", derive(Debug))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unnecessary since s!
macro already derives it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is s_no_extra_traits
!
I guess since we implement everything on mcontext
, ucontext
could go into s
..
upd: well after adding Hash
we do
#[cfg_attr(feature = "extra_traits", derive(Debug))] | ||
pub struct ucontext_t { | ||
pub uc_sigmask: ::sigset_t, | ||
pub uc_mcontext: ::mcontext_t, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes importing failure:
error[E0412]: cannot find type `mcontext_t` in the crate root
--> src/unix/bsd/freebsdlike/freebsd/x86_64/mod.rs:87:28
|
87 | pub uc_mcontext: ::mcontext_t,
| ^^^^^^^^^^ did you mean `ucontext_t`?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess these ancient rustcs were single pass and the pub use self::align::*
at the bottom doesn't bring it into this scope?!
Screw it, moving ucontext_t
into the align module too.
c638821
to
443cf7b
Compare
Okay, now looks fine to me! |
I just got 'libxul.so: Undefined symbol "mq_close"' when rebuilding Firefox.. How did no one catch this before?? This is correct for both FreeBSD and DragonFly: https://github.com/freebsd/freebsd/blob/master/lib/librt/Symbol.map https://github.com/DragonFlyBSD/DragonFlyBSD/blob/e7ab884bd49753f8884eb597d10d6569a08fa0df/lib/librt/mq.c https://github.com/DragonFlyBSD/DragonFlyBSD/blob/e7ab884bd49753f8884eb597d10d6569a08fa0df/lib/librt/aio.c
sys/stat.h is a machine-independent header, but it has ifdefs for i386. The version that was called x86_64.rs should be used on powerpc64 too, but I don't have a machine to test that on.
Wide chars are unsigned when normal chars are
It was picked up transitively on >10, but tests failed on 10
…renames Plus, add new constants for sysctls that give names to existing magic numbers. https://reviews.freebsd.org/rS350749 https://reviews.freebsd.org/rS352486
443cf7b
to
962b984
Compare
Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
For the case of aio_ functions, nobody noticed the lack of librt before because it isn't required. Linking to librt is only required if you wish to use Using Your change was of course correct as regards mq_ functions. |
On FreeBSD, the aio_ functions require librt _only_ if they use SIGEV_THREAD completion notification. However, due to Rust's originally poor support for C unions, libc doesn't even expose some of the fields of struct sigevent that SIGEV_THREAD requires. Accordingly, there is no need to link librt to programs using aio via libc. This change partially reverts 8c23f77 from PR rust-lang#1630 .
On FreeBSD, the aio_ functions require librt _only_ if they use SIGEV_THREAD completion notification. However, due to Rust's originally poor support for C unions, libc doesn't even expose some of the fields of struct sigevent that SIGEV_THREAD requires. Accordingly, there is no need to link librt to programs using aio via libc. This change partially reverts 8c23f77 from PR rust-lang#1630 . While I'm here, fix the linkage of lio_listio on DragonflyBSD. It _does_ require librt.
aio functions do not require librt on FreeBSD On FreeBSD, the aio_ functions require librt _only_ if they use SIGEV_THREAD completion notification. However, due to Rust's originally poor support for C unions, libc doesn't even expose some of the fields of struct sigevent that SIGEV_THREAD requires. Accordingly, there is no need to link librt to programs using aio via libc. This change partially reverts 8c23f77 from PR #1630 . While I'm here, fix the linkage of lio_listio on DragonflyBSD. It _does_ require librt.