this fixes the siginfo_t compilation errors

[dhuseby]

@alexcrichton this fixes the siginfo_t problem with netbsd.

[dhuseby]

I also added some missing externs for netbsd.

[dhuseby]

@alexcrichton BTW, I'm 95% done with bootstrapping for NetBSD. My https://github.com/dhuseby/rust-cross-toolkit is able to get through the first three stages for NetBSD. It can build a stage0 rustc but the rustc segfaults when calling https://github.com/dhuseby/rust/blob/master/src/libstd/sys/unix/stack_overflow.rs#L131

For some reason, the compiler emits code to call the signal 13 compatibility trampoline code instead of just calling the main sigaction syscall. That's as far as I've gotten in the debugging. I need to install some debug symbols and debug the NetBSD kernel to see why it's returning ENOSYS and segfaulting on that call. It's probably just some alignment issues or something. The weirdest part is if I use clang to compile C code that calls sigaction exactly the same way stack_overflow.rs does, it generates the correct code to execute the sigaction syscall. So that makes me think that the problem isn't with LLVM.

Once I can figure that out, I'm pretty sure I'll be able to build snapshots for NetBSD and set up a build bot for that OS too.

[semarie]

@dhuseby if you use master branch of rustc for building, be aware that llvm could produce bugged code for x86-64 architecture. It is what I hited with OpenBSD (rust-lang/rust#31363). See also rust-lang/rust#31505.

[dhuseby]

@semarie wow, those bugs are nasty. I'm just trying to figure out why I'm getting signal 13 trampoline code generated for a call to sigaction. I'll know more in a few days.

[alexcrichton]

It looks like the build is failing because the cfg_if! macro isn't exactly the most robust in the world (it doesn't handle this #[cfg]-like situation.

Perhaps, though the struct could be defined as:

pub struct siginfo_t {
    pub si_signo: ::c_int,
    pub si_code: ::c_int,
    pub si_errno: ::c_int,
    #[cfg(target_pointer_width = "64")]
    __pad1: ::c_int,
    pub __pad: [u64; 13],
}

That should mirror what we do in Linux which is to not give you si_addr but rather where the union starts. The padding should only be there for 64 bit as well, I think, right?

This'll require more support code in std but it's a little more faithful to the representation on the system I think.

[dhuseby]

@alexcrichton I just removed the #[cfg] for now since we don't support 32-bit netbsd anyways.

[dhuseby]

rebased

[alexcrichton]

This probably wants to be pub to be accessible from other crates

[dhuseby]

you're right, I was tired and making dumb mistakes I guess :)

[alexcrichton]

Could you also squash the commits down into one as well?

[dhuseby]

@alexcrichton squashed and fixed.

[gandro]

@dhuseby Regarding the ENOSYS errors: Just a wild guess, but some compatibility system calls on NetBSD are just not available on x86_64, since they have been deprecated long since before x86_64 even existed. So you need to make sure not use the compatibility functions (most of them are really, really old).

The libc crate used to define the #[link_name] for the affected NetBSD functions to avoid calling the legacy versions (see PR rust-lang/rust#28543) for exactly for this reason, but unfortunately this got lost during the great libc refactoring.

I think the reason your code works in C, but not in Rust, is that NetBSD C header files defines alternative linker symbols for the replacements. If you call sigaction in C, it actually actually links against __sigaction14. So Rust needs to define #[link_name = "__sigaction14"] on the sigaction declaration. See also alexcrichton/ctest#1

Unfortunately I've been too busy in the last few months to maintain Rusts NetBSD port myself. I have some time now, so let me know if I can help out.

[dhuseby]

@gandro it was a #[link_name] problem. I have a patch inbound.