2 ms·

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

by inigyou 4mo ago

bigfishrunning 4mo ago
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.
- inigyou 4mo ago
  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)
  - matheusmoreira 4mo ago
    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.
- matheusmoreira 4mo ago
  > 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.
  - inigyou 4mo ago
    You just call syscall(syscall number, arguments) in glibc
    - matheusmoreira 4mo ago
      I don't want to have to link against glibc. Nobody should need to do that.
      - inigyou 4mo ago
        then you first write syscall or copy it from glibc, and then you do that.
        matheusmoreira 4mo ago
        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.
matheusmoreira 4mo ago
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.

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

by inigyou 4mo ago

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.

inigyou 4mo ago
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)
- matheusmoreira 4mo ago
  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.
matheusmoreira 4mo ago
> 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.
- inigyou 4mo ago
  You just call syscall(syscall number, arguments) in glibc
  - matheusmoreira 4mo ago
    I don't want to have to link against glibc. Nobody should need to do that.
    - inigyou 4mo ago
      then you first write syscall or copy it from glibc, and then you do that.
      - matheusmoreira 4mo ago
        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.

matheusmoreira 4mo ago

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.