Implement basic NetBSD/amd64 support #28543
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Not precisely part of this change, but it would probably be in the best interest of the NetBSD port to move the functions marked with link_name out of libstd into the libc crate, so crates outside of rustc have access to the correct declarations. |
| extern { | ||
| fn clock_gettime(clk_id: libc::c_int, tp: *mut libc::timespec) -> libc::c_int; | ||
| } | ||
| #[cfg(target_os = "netbsd")] | ||
| extern { | ||
| #[link_name = "__clock_gettime50"] |
There was a problem hiding this comment.
These sorts of #[cfg] attributes are probably best done via:
#[cfg_attr(target_os = "netbsd", link_name = "__clock_gettime50")]Could this happen for the modifications to liblibc as well?
|
Rebased. Found some more functions using the wrong linker symbol, hopefully these should be all. @alexcrichton I addressed your comments, now uses @eefriedman Good point. Do I understand it correctly that you want to move those functions into the libc create for all platforms, and not just for NetBSD? |
|
Yes, I mean for all platforms. |
| __magic: libc::c_uint, | ||
| __opaque: [u8; __PTHREAD_COND_SIZE__], | ||
| } | ||
| #[repr(C, packed)] |
There was a problem hiding this comment.
Is the packed annotation her needed for alignment/size? It looks like there's no padding here so it may not be needed?
There was a problem hiding this comment.
Oh dear, you are right, this is completely wrong. I added packed to avoid padding, which is indeed not needed. But as a side effect it completely messed up alignment - even without packed the alignment was wrong for some types, I pushed a fix. Rust and C agree now on size and alignment for these four types.
These changes introduce the ability to cross-compile working binaries for NetBSD/amd64. Previous support added in PR #26682 shared all its code with the OpenBSD implementation, and was therefore never functional (e.g. linking against non-existing symbols and using wrong type definitions). Nonetheless, the previous patches were a great starting point and made my work significantly easier. 😃 Because there are no stage0 snapshots for NetBSD (yet), I used a cross-compiler for NetBSD 7.0 RC3 and only tested some toy programs (threading and channels, stack guards, a small TCP/IP echo server and some other platform dependent bits). If someone could point me to documentation on how to generate a stage0 snapshot from a cross-compiler I'm happy to run the full test suite. A few other notes regarding Rust on NetBSD/amd64: - To preserve binary compatibility, NetBSD introduces new symbols for system call wrappers on breaking ABI changes and keeps the old (legacy) symbols around, see [this documentation](https://www.netbsd.org/docs/internals/en/chap-processes.html#syscalls_master) for some details. I went ahead and modified the `libc` and `std` crate to use the current (renamed) symbols instead of the legacy ones where I found them, but I might have missed some. Notably using the `sigaction` symbol (deprecated in 1998) instead of `__sigaction14` even triggers SIGSYS (bad syscall) on my amd64 setup. I also changed the type definitions to use the most recent version. - NetBSD's gdb doesn't really support position independent executables, so you might want to turn that off for debugging, see [NetBSD Problem Report #48250](https://gnats.netbsd.org/48250). - For binaries invoked using a relative path, NetBSD supports `$ORIGIN` only for short `rpath`s (~64 chars or so, I'm told). If running an executable fails with `execname not specified in AUX vector: No such file or directory`, consider invoking the binary using its full absolute path.
separate use code between openbsd/netbsd netbsd use c_int and c_uint, but openbsd not, resulting a unused_import error. r? @alexcrichton problem introduced by #28543
These changes introduce the ability to cross-compile working binaries for NetBSD/amd64. Previous support added in PR #26682 shared all its code with the OpenBSD implementation, and was therefore never functional (e.g. linking against non-existing symbols and using wrong type definitions). Nonetheless, the previous patches were a great starting point and made my work significantly easier. 😃
Because there are no stage0 snapshots for NetBSD (yet), I used a cross-compiler for NetBSD 7.0 RC3 and only tested some toy programs (threading and channels, stack guards, a small TCP/IP echo server and some other platform dependent bits). If someone could point me to documentation on how to generate a stage0 snapshot from a cross-compiler I'm happy to run the full test suite.
A few other notes regarding Rust on NetBSD/amd64:
libcandstdcrate to use the current (renamed) symbols instead of the legacy ones where I found them, but I might have missed some. Notably using thesigactionsymbol (deprecated in 1998) instead of__sigaction14even triggers SIGSYS (bad syscall) on my amd64 setup. I also changed the type definitions to use the most recent version.$ORIGINonly for shortrpaths (~64 chars or so, I'm told). If running an executable fails withexecname not specified in AUX vector: No such file or directory, consider invoking the binary using its full absolute path.