sunfishcode / c-ward

An implementation of libc written in Rust

c-ward

An implementation of libc written in Rust

c-ward is an implementation of the libc ABI written in Rust.

It consists of two crates:

• c-scape, which is no_std, and
• c-gull, which pulls in c-scape and additionally provides features using std.

It is a goal of c-ward to be a C ABI layer on top of Rust-idomatic libraries, rather than to have significant implementation code of its own.

In theory c-ward could be extended to be ABI-compatible with different platforms, however currently it is only known to be ABI-compatible with *-unknown-linux-gnu* platforms.

The primary way this is used is through Mustang and Eyra, as their libc implementations. It can also be used as a regular library in "coexist-with-libc" mode.

Similar crates

Another libc implementation is relibc. tinyrlibc is a very minimal set of libc functions for bare-metal embedded platforms.

Where's the #![no_builtins]?

Normally, a libc implementation would use #[no_builtins] to prevent compilers from noticing the bodies of libc functions implement the semantics of libc functions and replacing them with calls, which effectively makes them uselessly recursive calls to themselves.

However, #[no_builtins] is too pessimistic, because we don't need to disable all pattern matching, just these specific cases.

So instead, c-scape and c-gull are just careful to avoid open-coding functions which are known to get pattern-matched into builtins, by just calling the compiler_builtins implementations directly themselves. This way, we can avoid using #![no_builtins].

c-ward's Issues

Support setjmp/longjmp and sigsetjmp/siglongjmp

Many C projects depend on this. For example lua and musl's dynamic linker. And (when __builtin_setjmp/__builtin_longjmp support is not detected) Wasmtime depends on it too.

`strverscmp` orders "00" before "000"

According to the strverscmp documentation, 000 is ordered before 00, which means that strverscmp("000", "00") should return a negative value, however it currently returns a positive value.

Specifically, running this:

fn main() {
    extern "C" {
        fn strverscmp(a: *const libc::c_char, b: *const libc::c_char) -> libc::c_int;
    }
    unsafe {
        dbg!(strverscmp("000\0".as_ptr().cast(), "00\0".as_ptr().cast()));
    }
}

prints the value 48.

@KGrewal1

Make a list of all implemented libc functions?

Hello @sunfishcode.

Thanks for working on this project!

Is it possible to add a list of all implemented and unimplemented libc functions? I think it will make it easier for people to see if c-scape supports the ones that they need. It should also allow to easily calculate the percentage and maybe graph it over time.

It's just a suggestion. Thanks.

Is this far enough along yet that it can make a "Linux distro"?

Bootloader -> kernel -> userspace where init is... Busybox shell?

So I guess this becomes, can the kernel and Busybox compile with this? I think you can build kernel with musl (I might have it wrong that you need libc to compile the kernel at all)

Split out NSS interaction code

The code that uses getent to interact with NSS is probably useful in contexts outside of eyra as well. It would be useful for implementing libc calls like, say, getpwuid_r.

`coexist-with-libc` mode has dubious value

The coexist-with-libc mode seems dubious for the vast majority of functions - anything that touches a shared header or struct (say, FILE or pthread_mutex_t) is likely to run into severe issues if it is used as a parameter in a function we do not implement.

In addition, it also seems not useful for the actual use cases this library supports - llvm-libc's version which replaces only the functions without shared structs (say FD functions or string functions) is only really useful because it's in C, Rust code likely uses its own.

no `invalid_mut` in `ptr`

Hello!

I've been trying to compile a toy miniquad project using both eyra and mustang, but unfortunately in both instances I got the same errors:

error[E0432]: unresolved import `core::ptr::invalid_mut`
 --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/brk.rs:2:17
  |
2 | use core::ptr::{invalid_mut, null_mut};
  |                 ^^^^^^^^^^^ no `invalid_mut` in `ptr`

error[E0432]: unresolved import `core::ptr::invalid_mut`
 --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/syscall.rs:5:5
  |
5 | use core::ptr::invalid_mut;
  |     ^^^^^^^^^^^^^^^^^^^^^^ no `invalid_mut` in `ptr`

error[E0425]: cannot find function `invalid_mut` in module `ptr`
   --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/process_.rs:192:32
    |
192 |         libc::AT_HWCAP => ptr::invalid_mut(rustix::param::linux_hwcap().0),
    |                                ^^^^^^^^^^^ not found in `ptr`

error[E0425]: cannot find function `invalid_mut` in module `ptr`
   --> /home/rice7th/.cargo/registry/src/index.crates.io-6f17d22bba15001f/c-scape-0.15.40/src/process_.rs:193:33
    |
193 |         libc::AT_HWCAP2 => ptr::invalid_mut(rustix::param::linux_hwcap().1),
    |                                 ^^^^^^^^^^^ not found in `ptr`

Some errors have detailed explanations: E0425, E0432.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `c-scape` (lib) due to 4 previous errors

Everything else compiles just fine.

Using the latest eyra/mustang and the latest nightly. Even adding the #![feature(strict_provenance)] feature gate does nothing.

Implement `fchownat`

We should implement the fchownat function, in a new c-scape/src/fs/chown.rs, and remove it from c-scape/src/todo.rs.

Rustix has a chownat function (which is rustix's name for fchownat) so what's needed for c-scape is to adapt that function to the C API.

undefined reference to `waitid'

Since rust-lang/rust#117957 - CI started to show error(it worked before):

  = note: /usr/bin/ld: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6af6cb20bb87a7a8.rlib(std-6af6cb20bb87a7a8.std.5f6dbc7992e36f36-cgu.0.rcgu.o): in function `std::sys::unix::process::process_inner::Process::try_wait':
          /rustc/2f8d81f9dbac6b8df982199f69da04a4c8357227/library/std/src/sys/unix/process/process_unix.rs:872: undefined reference to `waitid'
          /usr/bin/ld: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6af6cb20bb87a7a8.rlib(std-6af6cb20bb87a7a8.std.5f6dbc7992e36f36-cgu.0.rcgu.o): in function `std::sys::unix::process::process_inner::Process::wait::{{closure}}':
          /rustc/2f8d81f9dbac6b8df982199f69da04a4c8357227/library/std/src/sys/unix/process/process_unix.rs:851: undefined reference to `waitid'
          /usr/bin/ld: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6af6cb20bb87a7a8.rlib(std-6af6cb20bb87a7a8.std.5f6dbc7992e36f36-cgu.0.rcgu.o): in function `std::sys::unix::cvt':
          /rustc/2f8d81f9dbac6b8df982199f69da04a4c8357227/library/std/src/sys/unix/mod.rs:(.text._ZN3std3sys4unix7process13process_inner7Process4wait17h18922f9e5187f71aE+0x9d): undefined reference to `waitid'
          collect2: error: ld returned 1 exit status

Implement `ptsname` and `ptsname_r`

We should implement the ptsname and ptsname_r functions, in c-scape/src/termios_/mod.rs, and remove them from c-scape/src/todo.rs.

Rustix has a ptsname function, so what's needed for c-scape is to adapt that function to the C API.

I've labeled this a "good first issue", though that's admittedly relative. It requires familiarity with C strings, raw pointers, and static buffers.

Move Eyra into a separate repo?

On one hand, Eyra has almost no code; it's just dependencies on other crates. It doesn't really need its own repo.

On the other, Eyra is an outward-facing personality, with c-gull/c-scape as somewhat encapsulated implementation details, so it might be nice to let Eyra have its own place.

Or maybe Eyra should be merged back into Mustang, now that they're both very close to the same thing.

Or maybe this is the time to introduce a new github organization, as @notgull suggested, where Origin, c-ward, Mustang, Eyra, and some of the smaller helper crates can all live, under an umbrella.