I want to know what happen when compiler encountered "fopen()" in C program.
Where is the function which calls the 'open' system call?
I see fopen() is declared in stdio.h, but I cannot find where it is implemented!!
I want to see where system call number and other parameters of system calls are written to CPU registers.
Thank you.
You can look at glibc implementation here: https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/iofopen.c;h=be2bbb663bc04093493313af266fcdad85c62c28;hb=HEAD#l95
_IO_new_fopen is a symbolic constant (macro) that expands to fopen The fopen function is a wrapper around an internal function to a libio function.
fopen isn't a system call, you might be confusing it with open which is a system call.
Related
i am trying to find the select() source code (linux, i386 arch) in the glibc source code,
but i cannot find anything (related to the said architecture)
Could anybody point me to the select() source code ?
mh's answer is pretty good, but I will try to be more specific:
select is Linux system call, not libc function. It's source code could be found here.
libc has only wrapper for calling (executing) linux system call. Wrapper for select syscall is created on the fly at build time, because select is in syscalls.list file.
select() is not a function of the libc, but a kernel function, so you need to take a look into the kernel source.
You can tell this by looking into the man page: If it is in section 2, it's a kernel function, if it's in section 3, it's a function of the standard C library, in your case the glibc.
Edit: Like some other people remarked correctly (thank you!), a function described in section 2 is officially called a system call and it is actually a call to a library that wraps the operating system's actual call interface.
I know that read is system call. But when I read man 2 and man 3 of read it shows me different explanation. So , I am suspecting that read has library function and system call. In such case if I use read in my c program, whether compiler will consider read as library function or system call Please explain me on this confusion.
It doesn't. System calls are present in libc (the C standard library) just like library functions are. The implementations of system calls in libc are just "stubs" which invoke system-specific methods of calling into the kernel.
I'm assuming you're on Linux. On that platform, the manpage read(2) describes the Linux system call, while read(3) describes the POSIX specification for read, if you have the POSIX manpages installed. The latter is in category 3 because POSIX doesn't specify a difference between system calls and library functions.
There's only one read in libc, which is (a thin wrapper around) the system call.
I know it sounds a little stupid but is there a way to prove that on Windows:
fopen function calls winapi function CreateFile (or CreateFileEx)
fread function calls winapi function ReadFile (or ReadFileEx)
If there is a more general way to determine how some C library functions call the winapi functions, I'm also happy with that as an answer.
We're having a debate and I'm interested in some proof. I'm mainly interested in Visual C.
Visual C comes with the source code for the C runtime library. Would that settle things?
Break into the application with your debugger and put a breakpoint on the functions you target (they are implemented in kernel32.dll). Try to e.g. step over a fopen call. If your breakpoint is hit, then fopen calls CreateFile.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
C fopen vs open
What is the difference between open() and fopen() in C language?
One is part of the standard c library (fopen) so you can expect it to be present on all hosted c compiler setups. This function returns a FILE* which can be operated on by the functions in <stdio.h>.
The other (open) is a system call/function not specified by the c standard (however, i believe it is part of the POSIX standard) and therefore only guaranteed to exist on select platforms which claim to support it. This returns an int which represents a file, this can be operated on using read/write and other similar functions.
open() is a standardised system call provided by a POSIX compliant operating system (most POSIX-like operating systems also have the open() system call). fopen() is a C library function provided by the C implementation and/or runtime library.
fopen() allows for buffered and/or formatted input/output, whereas open() is generally used for more straightforward IO. It is possible for the fopen() function to be implemented using the open() system call.
As others said open() is a system call through POSIX standard, mostly supported by UNIX family of operating systems. It returns 'int' indicating the file descriptor being opened.
While on the other hand fopen() is provided by C-library and it returns a FILE* pointing to the file being opened.
I'm currently working on a project where I need to track the usage of several system calls and low-level functions like mmap, brk, sbrk. So far, I've been doing this using function interposition: I write a wrapper function with the same name as the function I'm replacing (mmap for example), and I load it in a program by setting the LD_PRELOAD environment variable. I call the real function through a pointer that I load with dlsym.
Unfortunately, one of the functions I want to wrap, sbrk, is used internally by dlsym, so the program crashes when I try to load the symbol. sbrk is not a system call in Linux, so I can't simply use syscall to call it indirectly.
So my question is, how can I call a library function from a wrapper function of the same name without using dlsym? Is there any compiler trick (using gcc) that lets me refer to the original function?
see ld's option --wrap symbol. From the man page:
--wrap symbol Use a wrapper function for symbol. Any undefined
reference to symbol will be resolved
to "__wrap_symbol". Any undefined
reference to "__real_symbol" will
be resolved to symbol.
This can be used to provide a
wrapper for a system function. The
wrapper function should be called
"__wrap_symbol". If it wishes to call
the system function, it should call
"__real_symbol".
Here is a trivial example:
void *
__wrap_malloc (size_t c)
{
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
}
If you link other code with this
file using --wrap malloc, then all
calls to "malloc" will call the
function "__wrap_malloc" instead. The
call to "__real_malloc" in
"__wrap_malloc" will call the real
"malloc" function.
You may wish to provide a
"__real_malloc" function as well, so
that links without the --wrap option
will succeed. If you do this, you
should not put the definition of
"__real_malloc" in the same file as
"__wrap_malloc"; if you do, the
assembler may resolve the call before
the linker has a chance to wrap it to
"malloc".
The other option is to possibly look at the source for ltrace, it is more or less does the same thing :-P.
Here's an idea though. You could have your LD_PRELOAD'ed library change the PLT entries to point to your code. This you technically the sbrk() function is still callable from your code nativly.
You can examine function invocation unobtrusively using tools such as:
gdb
ltrace
systemtap
These tools allow a monitor program to inform you when a function is called, and allow you to interrogate the arguments.
The main differences are:
gdb is interactive, but powerful
ltrace simple to use, but you can only print the function name
systemtap is not interactive, but it can be very fast, and is powerful.
If you are running a host system with glibc, the libc has some internal back end to the runtime dynamic linker that I used some time ago. If I recall correctly, I think it's called '__libc_dlsym'. (To check, "$ readelf -s /usr/lib/libc.a | grep dlsym" should help.) Declare it as an externally linked function with the same arguments and return value that dlsym has and use it to wrap dlsym itself.
Does truss not work on your system? It works perfectly for this kind of things here on Solaris.