Or perhaps a `--target` flag that says "I'm targeting the linux kernel, not userspace, libcall these symbols (existing kernel functionality) rather than those (glibc interfaces)."
Or perhaps a `--target` flag that says "I'm targeting the linux kernel, not userspace, libcall these symbols (existing kernel functionality) rather than those (glibc interfaces)."
That won't solve it. Fil-C's memory safety relies on the Fil-C runtime
Just as the sanitizers have a runtime, the linux kernel has a re-implementation of those runtimes (the linux kernel does not link libgcc/compiler_rt) and IIRC the compiler will work differently (I forget which flags control that). Prior art here.
The sanitizer runtime is not nearly as complex as the Fil-C runtime.
Sanitizers don't have to deal with:
- https://fil-c.org/fugc
- https://fil-c.org/safepoints
Oh and it's not clear if the current revision of the capability model would work with memory mapped IO: https://fil-c.org/invisicaps
Does fil-c have a way of disabling the capability model for regions of code? (Rust's `unsafe` blocks come to mind).
Maybe if I ask enough stupid questions, you'll get pissed and get the kernel to build/work with fil-c just to prove a stranger on the internet wrong. :P
> Does fil-c have a way of disabling the capability model for regions of code? (Rust's `unsafe` blocks come to mind).
Nope
> Maybe if I ask enough stupid questions, you'll get pissed and get the kernel to build/work with fil-c just to prove a stranger on the internet wrong. :P
I love this attitude! :-)