glibc 源代码中的系统调用在哪里

Question

So I was looking through the linux glibc source and I don't see where it actually does anything. The following is from io/chdir.c but it is indicative of many of the source files. What's going on here? Obviously I am missing something. What's the secret, where does it make a system call or actually do something?

stub_warning is some legacy craziness. __set_errno seems to be a simple macro that sets errno . And while I find a million usages of weak_alias I don't see it defined anywhere.

Is there a helpful guide to understanding how glibc works somewhere?

#include <errno.h>
#include <stddef.h>
#include <unistd.h>

/* Change the current directory to PATH.  */
int
__chdir (path)
     const char *path;
{
  if (path == NULL)
    {
      __set_errno (EINVAL);
      return -1;
    }

  __set_errno (ENOSYS);
  return -1;
}
stub_warning (chdir)

weak_alias (__chdir, chdir)
#include <stub-tag.h> 

Answer 1

What you've found is a stub function for systems it's not implemented on. You need to look under the sysdeps tree for the actual implementation. The following may be of interest:

• sysdeps/unix/sysv/linux
• sysdeps/posix
• sysdeps/i386 (or x86_64 or whatever your cpu arch is)

Answer 2

The actual system call code for chdir() is auto-generated on most systems supported by glibc , by the script make-syscalls.sh . That's why you can't find it in the source tree.

Answer 3

That's a generic stub that is used if another definition doesn't exist; weak_alias is a cpp macro which tells the linker that __chdir should be used when chdir is requested, but only if no other definition is found. (See weak symbols for more details.)

chdir is actually a system call; there will be per-OS system call bindings in the gibc source tree, which will override the stub definition with a real one that calls into the kernel. This allows glibc to present a stable interface across systems which may not have all of the system calls that glibc knows about.

Answer 4

Note that the actual system calls aren't defined anywhere in the source tree - they're generated at build time from syscalls.list (linked is the one in sysdeps/unix, there are additional ones further down), a series of macros insysdep.h (linked linux/i386), and a script that actually generates the source files.