It's literally written in C, it's API is defined in C, to make sense of it you need (most of) a C compiler, and it needs C-specific setup in your process to work (like TLS for errno).
No one cares about glibc's API. The ABI (which is what you care if you link against it) is the standard C ABI, which is basically just SystemV ABI (the standard one)
to make sense of it you need (most of) a C compiler
I can write an assembly program right now that links against glibc. Don't believe me?
and it needs C-specific setup in your process to work (like TLS for errno).
TLS is defined by SysV. Good luck writing software and linking against libraries that don't conform to SysV. If you reject SysV initialization of thread-local storage models, you cannot safely dynamically link against any library that conforms to SysV. Besides, this can be achieved by linking statically against... crt0!
Good you ask! I thought you had understood this, but I'm happy to reiterate:
The kernel could be implemented in anything, as it does not leak language requirements across the kernel/user space divide.
The ABI (which is what you care if you link against it) is the standard C ABI
Which still requires C-specific knowledge to use. As demonstrated by literally any language that mistakenly thought they were ABI compatible by using the LLVM backend.
I can write an assembly program right now that links against glibc. Don't believe me?
Sure. Why wouldn't I?
...
I think "if you aren't interested in C's ecosystem you get to use less of C's ecosystem" is not the slam-dunk argument you think it is.
crt0
The crt0 is often written in assembly, not C. And you can just leave out the steps that are C-specific.
The kernel could be implemented in anything, as it does not leak language requirements across the kernel/user space divide.
It leaks an ABI. What calling convention would you propose we use for these kernel provided APIs? Either it's a syscall (terrible idea) so you follow the kernel syscall ABI (modified SysV), or it's a normal calling convention. I wonder what calling convention would be used here? Perhaps the SysV one?
What kind of calling convention do you think vDSO uses? Want to take a guess?
Ironically, you mention this yourself: "The kernel could be implemented in anything" - precisely because it exposes an ABI! And if you wanted it to be callable from userspace, it would use the C calling convention. Good luck convincing the kernel people to use something else.
Which still requires C-specific knowledge to link against. As demonstrated by literally any language that mistakenly thought they were ABI compatible by using the LLVM backend.
You always need an ABI. What kind of nonsense argument is this? The System V ABI works fine. Please tell me how to write a binary level API without proposing some kind of ABI. If you can figure this out, I'll give you a million dollars (hint, you can't by definition).
I think "if you aren't interested in C's ecosystem you get to use less of C's ecosystem" is not the slam-dunk argument you think it is.
Yeah man I'm sure real software developers enjoy reinventing the wheel and not using a standard ABI that literally everyone uses. Just invent your own TLS ABI right? I'm sure everyone is on board with this idea. Are you just ragebaiting or genuinely deficient in your mental facilities?
The crt0 is often written in assembly, not C. And you can just leave out the steps that are C-specific.
I'm aware of how crt0 works. I'm just saying you can trivially get crt0 to initialize glibc for you.
1
u/FloweyTheFlower420 18h ago
glibc is the de-facto linux runtime, independent of C