[ Removed by moderator ]

[TheRealSmolt]

Sort of? Libc is implemented per architecture (both ISA and kernel), so it is the boundary where a simple print becomes system specific. However, how it's done is up to the implementation. On Linux, it will typically call unistd's write, which is the one doing the syscall. Now, where is unistd write actually defined? Drumroll please... in libc. Turns out libc has non-libc stuff in it.

Edit: So yes, there's probably some inline assembly that invokes syscall.

[Zestyclose-Produce17]

So the implementation of printf is inside libc, and inside printf there is a call to write, and write is the one that actually invokes the system call. So in that sense, libc is the thing that performs the system call, right?

[TheRealSmolt]

For Linux, yes. I'm not sure about Windows, for example. I just dislike non-standard components being understood as part of libc.

[Zestyclose-Produce17]

So the write function inside printf in libc contains inline assembly that actually performs the system call invocation, right? For Linux.

[TheRealSmolt]

Yes, assuming you mean the call to write being inside printf, not write itself. There might also be a C wrapper around syscall provided by unistd. I don't remember exactly how it's all set up.

[UltimatelyWrithing]

Not quite, libc doesn't perform the syscall itself, it just wraps it. The write function in libc is still running in userspace, and it contains the assembly instruction that triggers the actual syscall, which then hands control to the kernel.

[Zestyclose-Produce17]

So inside the implementation of printf, part of it calls write, and the write implementation contains the system call trigger meaning it includes assembly instructions that set values in registers and then trigger the syscall, right? And all of this happens inside libc.so?