I don't expect for a moment that Fil-C might supplant normal C under normal circumstances. Calling normal C "yolo-C" is dishearteningly pompous. Just because you've invented a C environment with a different tradeoff, people not interested in it are not automatically irresponsible (which is what you are suggesting with "yolo", of course).
Does fil-clang have `-fno-` flag to control disabling fil-c stuff?
Does the fil-c runtime depend on specifics from glibc, or is it that LFS doesn't support building with musl?
> We need to retain the Yolo GCC for compiling the Linux kernel.
Probably can replace that with s/the Linux kernel/glibc/. glibc maintainers have started upstreaming patches for building glibc with clang, but not sure yet what's the latest on that (large) patch series.
If you do get around to adding the flag, consider a suggestion for the color of bikeshed: `-fyolo`. (Can't find my April Fool's clang patch for adding `-feverything`; hard to search the phab archive)
I think the way to do that is via something like l4linux, so that the ultra low level bits of the Fil-C runtime aren't relying - circularly - upon kernel functionality compiled with Fil-C that rely on that runtime.
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)."
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.
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
The only thing standing in the way of it working on real HW is just making sure the kernel is configured properly for it. Like right now the kernel config file is the result of enabling those things that work on the virtual devices that HyperV and VMware provide.
The right answer is modular kernel and something like initramfs and modprobe or whatnot. That kind of work has nothing to do with Fil-C; it’s just distro engineering
> Pizlix requires you to set up your machine thusly:
should say Pedantic Sunday: Happy Hanukkah!Of course you are right!
I find the repeated "yolo" qualifications very tiresome, yawn-inducing.
At least in this article:
https://fil-c.org/runtime
the term "classic C" is still used.
I don't expect for a moment that Fil-C might supplant normal C under normal circumstances. Calling normal C "yolo-C" is dishearteningly pompous. Just because you've invented a C environment with a different tradeoff, people not interested in it are not automatically irresponsible (which is what you are suggesting with "yolo", of course).
> The kernel is compiled with Yolo-C. So that you can compile the kernel, a copy of GCC is installed in /yolo/bin/gcc.
Fil, you can compile the Linux kernel will clang+lld. `make LLVM=1` https://docs.kernel.org/kbuild/llvm.html
Gotcha. I am using gcc for building yolo-glibc, and the version I'm building (2.40) requires gcc.
So if I used clang, then I'd have three compilers (yolo-clang, gcc, fil-clang) instead of two (gcc, fil-clang).
Does fil-clang have `-fno-` flag to control disabling fil-c stuff?
Does the fil-c runtime depend on specifics from glibc, or is it that LFS doesn't support building with musl?
> We need to retain the Yolo GCC for compiling the Linux kernel.
Probably can replace that with s/the Linux kernel/glibc/. glibc maintainers have started upstreaming patches for building glibc with clang, but not sure yet what's the latest on that (large) patch series.
>Does fil-clang have `-fno-` flag to control disabling fil-c stuff?
No. I could add a flag like that, but that would make my patch to clang larger, which would make rebasing to new clang versions harder.
So I'm choosing not to add such a flag. For now.
> Do you depend on glibc, or is it that LFS doesn't support building with musl?
I support both glibc and musl.
LFS is glibc-based.
If you do get around to adding the flag, consider a suggestion for the color of bikeshed: `-fyolo`. (Can't find my April Fool's clang patch for adding `-feverything`; hard to search the phab archive)
Love it!!
Filip, do you plan to support building the kernel with fil-c? What's the limiting factor right now on supporting that?
I think the way to do that is via something like l4linux, so that the ultra low level bits of the Fil-C runtime aren't relying - circularly - upon kernel functionality compiled with Fil-C that rely on that runtime.
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
> Supported Systems Pizlix has been tested inside VMware and Hyper-V on X86_64.
Any idea if it runs on real hardware ?
I am still just testing it in VMs.
The only thing standing in the way of it working on real HW is just making sure the kernel is configured properly for it. Like right now the kernel config file is the result of enabling those things that work on the virtual devices that HyperV and VMware provide.
The right answer is modular kernel and something like initramfs and modprobe or whatnot. That kind of work has nothing to do with Fil-C; it’s just distro engineering