Hacker News Reader

Comment by LtWorf | Hacker News Reader

> I had some GCC patches under development, and now I simply won't submit them.

Of course, of course… I also had found a proof to fermat's last theorem that fits in a single page but I'm not publishing it as well :D

View on HN

I had human authored GCC patches that added Linux system call builtins to GCC. I was in the middle of learning how GCC's code generation worked when my laptop fell onto the floor and my hard drive crashed, leading to the loss of the work. This was years ago, and you can even find some emails from me on the mailing list defending the feature.

AI helped me successfully restart that patch set, and take it much further than I got on my first try. Once I got that merged and perfected the contribution process, I was also planning to work on some of the feature requests that I posted on GCC's bugzilla, mainly an analyzer feature for tagged unions in C that verifies field accesses match their associated tags, and also a way to rename the "internal" symbols that GCC generates purely for aesthetic reasons.

Looks like all that stuff is gone now. Maybe it's for the best. Attempting to contribute to GNU projects hasn't exactly been a pleasant experience.

Can't you already do that with inline assembly pretty easily?

You generally don't have to, the Linux system calls are in the standard library anyway. Having GCC builtins for them is of questionable utility at best.

Even if the GP poster submitted these patches that may or may not exist, I'm not sure they would ever get merged.

But if you are the one writing the standard library, it's still easy. You can write asm volatile("syscall" : a bunch of stuff telling the compiler which values to put in which registers)

You can write that sort of asm code to call functions too, but the whole point of compilers is you shouldn't need to. It's a stable calling convention and I felt that the compiler should know how to emit the code.

> the Linux system calls are in the standard library anyway.

Nope. Not every system call is available. It took years before glibc got getrandom, for example. Others are straight up not supported because they break glibc's internals.

One could argue that it's always possible use the generic syscall function, but then what's the point of glibc? You can just get rid of it and use minimal shims, or compiler builtins, ideally.

> Having GCC builtins for them is of questionable utility at best.

It's useful if you're writing freestanding Linux programs. Great for eliminating all of the dependencies and writing minimal applications that target Linux directly. I wrote an entire lisp interpreter on top of nothing but Linux system calls.

> Even if the GP poster submitted these patches that may or may not exist, I'm not sure they would ever get merged.

Honestly I'm not sure either. The GCC maintainers didn't seem particularly convinced on the mailing list. It's the reason why I didn't bother to restart this work until years later. Claude made it easy enough to do it all over again.

Equally easy to drop. I'm gradually switching to Rust anyway.

You just call syscall(syscall number, arguments) in glibc

I don't want to have to link against glibc. Nobody should need to do that.

then you first write syscall or copy it from glibc, and then you do that.

Not sure why you're telling me this. As I said in my previous comment, I did do just that. I created a liblinux project just for this that eventually became my own freestanding lisp interpreter with Linux system call support. I'm now reviving the liblinux Rust crate so I can use it in a Rust network stack project.

You can, and that's exactly what the libraries do, and what I did in C, Rust, and Lisp. However, you shouldn't need to drop to assembly code. It's just a special calling convention. The compiler should know how to emit this code. JIT compilers too.

Reply on news.ycombinator.com