-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
FreeBSD does not require libc for syscalls #16590
Comments
All of the system call stubs in FreeBSD are machine generated from syscalls.master. If you want them as inline assembly, you can probably reuse the code. Note that the syscall calling convention is a little bit interesting on FreeBSD. Arguments are passed in the same location that they are for normal function calls (just replace the call instruction with syscall), with the exception of x8-64, where the SysV ABI defines a different register for one of the arguments (the trampoline is then just a register-register move and a syscall). The return values are more complex. On sensible architectures the error state is defined by the carry bit. If the carry bit is set, the return value register contains the errno value, if it is not set then it contains the result. This lets you branch on carry to detect failure. I believe MIPS and RISC-V use the second return register. |
Thanks for the tips! |
So, it's worth noting though that syscalls.master is version-specific and will change across FreeBSD major versions.
COMPATXX are optionally compiled in (IIRC, the current supported releases are included by default). I've assumed this is why FreeBSD has used libc for syscalls. |
I'm feeling a bit confused about whether there is a stable syscall ABI or not. What can an application developer expect if they provide a binary to a FreeBSD OS user? |
Just looked... it appears GENERIC includes COMPATXXX all the way back to 4 when it was introduced, so less of a concern than I thought. |
So my understanding is that basically, the ABI is stable, but it's possible for the user to exclude parts of it. I just discovered that by default, the whole thing is included... I had previously thought old syscalls were removed from the default kernel, but that's not true. |
So an application developer can expect that the binary will work for the version it was compiled for, and every version after that unless the user has built a custom kernel that removes backward compatibility. |
So the only real "gotcha" is making sure that the syscalls.master used is from the oldest supported FreeBSD, to avoid using syscalls from the future. |
For our purposes, Using syscall
Manually searching history we learn:
This looks very promising indeed! |
I'm not sure why the semver for each syscall would be needed unless the plan is to have each FreeBSD release from 4.x on be a unique target... not that I'm opposed to that, it just seems like a lot of unnecessary work, and makes targeting "FreeBSD" more complex than I would expect it to be. |
MIPS is no longer supported. |
@emaste can you offer any further wisdom here? If zig can rely on using oldest supported syscall tables then it could generate FreeBSD compatible binaries directly from any other OS/architecture which is very desirable. It would help FreeBSD to be a tier 1 target for zig compiler instead of a tier 2. |
It was introduced in 92da00b, after 5.0 and beforen 5.1. Reported in ziglang/zig#16590.
Yes, it's unfortunate that you had to hunt for this information, but this is correct. We may eventually remove COMPAT entries for very old FreeBSD versions from the default kernel configuration, but I expect that wouldn't happen for a minimum of a couple of decades after EOL.
If you're bypassing libc the libc stubs and associated symver isn't important. 12.x is the oldest supported FreeBSD release so that may be what you want to target, but it is EOL in a few more months and 13.x may be preferable. Rust and Go have similar issues. Discussions in rust-lang/rust#89058 and golang/go#48164 have a lot of information that is relevant here.
Hmm, let's see. swapoff was added by freebsd/freebsd-src@92da00b and indeed I see that is between 5.0 and 5.1. Fixed in freebsd/freebsd-src@b15f640
Generated by https://github.com/freebsd/freebsd-src/blob/main/sys/tools/makesyscalls.lua |
It was introduced in 92da00b, after 5.0 and beforen 5.1. Reported in ziglang/zig#16590. (cherry picked from commit b15f640)
It was introduced in 92da00b, after 5.0 and beforen 5.1. Reported in ziglang/zig#16590. (cherry picked from commit b15f640) (cherry picked from commit f4bb052)
From what I read so far, it seems that we don't need to do bring libc headers. If so, the last checkbox of #1759 can be marked done and #2876 can be closed |
freebsd will still have to be added to |
It was introduced in 92da00b, after 5.0 and beforen 5.1. Reported in ziglang/zig#16590.
source: https://lobste.rs/s/yjd59n/crt_free_2023_tips_tricks#c_viakfm
The task is to change this to
false
for FreeBSD:zig/lib/std/target.zig
Lines 398 to 413 in 282cb5e
And then go implement syscalls in the standard library via inline assembly like we already do for Linux rather than relying on libc for this target.
This is great news, hurray! We no longer need to build libc in order to cross-compile zig code for this target.
The text was updated successfully, but these errors were encountered: