I know that a call to the glibc "write" function calls in it's turn to the sys_call write function which is a kernel function.
because sys_call is a kernel function the CPU has to change the ring to zero store the processes registers and so on.
But does it always switches to kernel mode? for example, if i do

write(-1,buffer,LENGTH)

does it still tries to find it in the file descriptors array?
I see in the glibc source code that it does check for fd>0 but i don't see any jump to the sys_call there (it seems like the baracks for main() ends before any call to the alias_write.


/* Write NBYTES of BUF to FD. Return the number written, or -1. */
ssize_t
__libc_write (int fd, const void *buf, size_t nbytes)
{
if (nbytes == 0)
return 0;
if (fd < 0)
{
__set_errno (EBADF);
return -1;
}
if (buf == NULL)
{
__set_errno (EINVAL);
return -1;
}

__set_errno (ENOSYS);
return -1;
}
libc_hidden_def (__libc_write)
stub_warning (write)

weak_alias (__libc_write, __write)
libc_hidden_weak (__write)
weak_alias (__libc_write, write)
#include <stub-tag.h>

So the question is both:

Where does the glibc actually calls the sys_write
Is it true that glibc doesn't call the sys_write if fd<0?

This post on StackOverflow answers your question exactly:
–

To answer your original question, yes, a system-call ordinarily does occur. Or, depending on the architecture, something equivalent to a system call. Disk I/O in particular is a complicated process which makes heavy use of "buffering." Your process is typically allowed to continue while the actual write takes place asynchronously. (Although it can wait. sqlite often does this.)

So just for the clarification,
even if i sent write(-1,0,buffer) linux will not identify the problem in user space, and will switch to kernel space?
although the glibc checks came false?

I believe you could run your program under strace and answer that yourself in just a few minutes.

I'm trying to see if the libc function executed the int 0x80 (or any other form to change to kernel mode) call and changed to kernel mode.
sorry for the ignorance, but how can i do it with strace?

That's exactly what strace traces -- system calls. If you wanted to trace calls to the write(2) library function, you would use ltrace.

And why do you care ?.
Context switching takes place all the time. Literally. vmstat tells you that, but for the absolute number, try the following - repeat a couple of seconds later.

The system often spends more time in kernel mode than in user mode. (Still executing on behalf of the current process/thread.) All sorts of things require a system-call.

The x86 architecture implements call gates to provide more-direct transfers. They've since sort-of fallen out in favor of other mechanisms, but the essential notion is the same. User-land programs have frequent need to call specific subroutines (as determined solely by the OS), such that there is a perceived need to make the transition as rapid as possible.

A "system call" really is "a subroutine call," although it includes a change in the processor's privilege-level and is a one-way street: the requesting user-land program cannot make arbitrary calls into kernel space. Also, when the kernel switches back to user-land mode, it might have switched from one process/thread to another.

"This being Linux," you have all of the source-code that implements this magic on various architectures, and I suggest that it can be very, very informative and educational to "peek behind the curtain" and see what actually happens next.