Unix/Linux编程：系统调用与C库函数

拼搏现实的明天。 2022-10-14 05:26 211阅读 0赞

> **无论何时，只要执行了系统调用或者库函数，检查调用的返回状态以及确定调用是否成功，这是一条编程铁律**

# 系统调用 #

*  **系统调用是**受控的**内核入口**，借助于这一机制，进程可以请求内核以自己的名义去执行某些动作。
 *  **以应用程序编程接口(API)的形式，内核提供有一系列服务供程序访问**。这包括创建新进程、执行IO、为进程间调用管道等。手册页syscalls(2)列出了Linux系统调用

在深入系统调用的运作方式之前，务必关注以下几点

*  **系统调用将处理器从用户态切换到核心态，以便CPU访问受到保护的内核内存**
 *  系统调用的组成是固定的，每个系统调用都由一个唯一的数字来标识(程序通过名称来标识系统调用，对着以编号方案往往一无所知)。
 *  每个系统调用可辅之以一套参数，对用户空间(也即进程的虚拟地址空间)与内核空间之间(相互)传递的消息加以规范

从编程角度来看，系统调用与 C 语言函数的调用很相似。然而，在执行系统调用时，其幕后会历经诸多步骤。为说明这点，下面以一个具体的硬件平台—x86-32 为例，按事件发生的顺序对这些步骤加以分析

1.  应用程序通过调用 C 语言函数库中的外壳（wrapper）函数，来发起系统调用
2.  对系统调用中断处理例程来说，外壳函数必须保证所有的系统调用参数也用。通过堆栈，这些参数传入外壳函数，但内核却希望这些参数置入特定寄存器。因此，外壳函数会将上述参数复制到寄存器
3.  由于所有系统调用进入内核的方式相同，内核需要设法区分每个系统调用。为此，外壳函数会将系统调用编号复制到一个特殊的CPU寄存器(%eax)中
4.  外壳函数执行一条中断机器指令（int 0x80），引发处理器从用户态切换到核心态，并执行系统中断 0x80 (十进制数 128)的中断矢量所指向的代码

> 较新的 x86-32 硬件平台实现了 sysenter 指令，较之传统的 int 0x80 中断指令，sysenter指令进入内核的速度更快。2.6 内核及 glibc 2.3.2 以后的版本都支持 sysenter 指令

1.  为响应中断 0x80，内核会调用 system\_call()例程（位于汇编文件 arch/i386/entry.S 中）来处理这次中断，具体如下  
    a）在内核栈中保存寄存器值  
    b）审核系统调用编号的有效性  
    c）以系统调用编号对存放所有调用服务例程的列表（内核变量sys\_call\_table）进行索引，发现并调用相应的系统调用服务例程。若系统调用服务例程带有参数，那么将首先检查参数的有效性。例如，会检查地址指向用户空间的内存位置是否有效。随后，该服务例程会执行必要的任务，这可能涉及对特定参数中指定地址处的值进行修改，以及在用户内存和内核内存间传递数据（比如，在 I/O 操作中）。最后，该服务例程会将结果状态返回给 system\_call()例程。  
    d）从内核栈中恢复各寄存器值，并将系统调用返回值置于栈中。  
    e）返回至外壳函数，同时将处理器切换回用户态。
2.  如果系统调用服务例程的返回值表明调用有误，外壳函数会使用该值来设置全局变量errno。然后，外壳函数会返回到调用程序，并同时返回一个整数值，以表明系统调用是否成功

>  *  在Linux系统上，系统调用服务例程遵循的惯例是调用成功返回非负值。发生错误时，例程会对相应 errno 常量取反，返回一负值。C 语言函数库的外壳函数随即对其再次取反（负负得正），将结果拷贝至 errno，同时以-1 作为外壳函数的返回值返回，向调用程序表明有错误发生。
>  *  上述惯例所依赖的前提条件是系统调用服务例程，若调用成功则不会返回负值。可是，对于少数例程来说，这一前提并不成立。一般情况下，这也不会有问题，因为取反的 errno  
>     值范围不会与调用成功返回负值的范围有交集。不过，有一种情况，沿用这个惯例确实会出问题：系统调用 fcntl()的 F\_GETOWN 操作

下图以系统调用execvee()为例，展示了上文述及事件的发生序列。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]  
因此，从 C 语言编程的角度来看，调用 C 语言函数库的外壳（wrapper）函数等同于调用相应的系统调用服务例程。

为调试程序，或是研究程序的运作机制，可使用strace 命令，对程序发起的系统调用进行跟踪

# 库函数 #

一个库函数是构成标准C语言函数库的的众多库函数之一。库函数的用途多种多样，可用来执行以下任务：打开文件、将时间转换为可读格式，以及进行字符串比较等。

很多库函数(比如字符串操作函数)不会使用任何系统调用。另一方面，还有些库函数构建与系统调用层之上。例如，库函数 fopen()就利用系统调用 open()来执行打开文件的实际操作。**往往，设计库函数是为了提供比底层调用更为方便的调用接口**。例如，printf()函数可提供格式化输出和数据缓存功能，而 write()系统调用只能输出字节块。同理，与底层的 brk()系统调用相比，malloc()和 free()函数还执行了各种登记管理工作，内存的释放和分配也因此而容易许多

# 标准 C 语言函数库；GNU C 语言函数库（glibc） #

标准 C 语言函数库的实现随 UNIX 的实现而异。GNU C 语言函数库（glibc, http://www. gnu.org/software/libc/）是 Linux 上最常用的实现。

> Linux 同样支持各种其他 C 语言函数库，其中包括应用于嵌入式设备领域、受限内存条件下的 C 语言函数库。uClibc（http://www.uclibc.org/）和 dietlibc（http://www.fefe. de/dietlibc/）便是其中的两个例子

## 确定系统的glibc的版本 ##

有时，需要确定系统所安装的 glibc 版本。

在 shell 中:

*  可以直接运行 glibc 共享库文件—将其视为可执行文件—来获取 glibc 版本。这会输出各种文本信息，其中也包括了 glibc 的版本号

$ ldd hik  | grep libc
    	libc.so.6 => /lib64/libc.so.6 (0x00007fc173270000)
    $ /lib64/libc.so.6 
    GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.

*  getconf GNU\_LIBC\_VERSION

$ getconf GNU_LIBC_VERSION
    glibc 2.17

应用程序可通过测试常量和调用库函数这两种方法，来确定系统所安装的 glibc 版本：

*  从版本2.0开始，glibc 定义了两个常量：`__GLIBC__`和`__GLIBC_MINOR__`，供程序在编译时（在\#ifdef语句中）测试使用。在安装有 glibc 2.12 版本的系统上，以上两个常量的值分别为 2 和 12
 *  然而，如果程序在 A 系统上编译，而在 B 系统（安装了不同版本的 glibc）上运行，这两个常量作用就有限了。为应对这种可能，程序可以调用函数 gnu\_get\_libc\_version()，来确定运行时的 glibc 版本

$ man 3 gnu_get_libc_version
     NAME
           gnu_get_libc_version,  gnu_get_libc_release  -  get  glibc  version and
           release
    
    SYNOPSIS
           #include <gnu/libc-version.h>
    
           const char *gnu_get_libc_version(void);
           const char *gnu_get_libc_release(void);
    
    DESCRIPTION
           The function gnu_get_libc_version() returns a  string  that  identifies
           the glibc version available on the system.
    
           The  function  gnu_get_libc_release()  returns  a  string indicates the
           release status of the glibc version available on the system.  This will
           be a string such as stable.
    
    VERSIONS
           These functions first appeared in glibc in version 2.1.
    
    ATTRIBUTES
           For   an   explanation   of   the  terms  used  in  this  section,  see
           attributes(7).
    
           ┌────────────────────────┬───────────────┬─────────┐
           │Interface               │ Attribute     │ Value   │
           ├────────────────────────┼───────────────┼─────────┤
           │gnu_get_libc_version(), │ Thread safety │ MT-Safe │
           │gnu_get_libc_release()  │               │         │
           └────────────────────────┴───────────────┴─────────┘
    CONFORMING TO
           These functions are glibc-specific.
    EXAMPLE
           When run, the program below will produce output such as the following:
    
               $ ./a.out
               GNU libc version: 2.8
               GNU libc release: stable
    
       Program source
    
           #include <gnu/libc-version.h>
           #include <stdlib.h>
           #include <stdio.h>
    
           int
           main(int argc, char *argv[])
           {
        
               printf("GNU libc version: %s\n", gnu_get_libc_version());
               printf("GNU libc release: %s\n", gnu_get_libc_release());
               exit(EXIT_SUCCESS);
           }

# 处理来自系统调用和库函数的错误 #

*  几乎每个系统调用和库函数都会返回某类状态值，用以表明调用成功与否。要了解调用是否成功，必须坚持对状态值进行检查。若调用失败，那么必须采取相应行动。至少，程序应该显示错误消息，警示有意想不到的事件发生。
 *  不检查状态值，少敲几个字，听起来的确诱人（尤其是见识到了不检查状态值的UNIX/Linux 程序以后），但实际却得不偿失。认定系统调用或库函数“不可能失败”，不对状态返回值进行检查，这会浪费掉大把的程序调试时间
 *  少数几个系统函数在调用时从不失败。例如，getpid()总能成功返回进程的 ID，而\_exit()总能终止进程。无需对此类系统调用的返回值进行检查。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221014/90ef4afd4f1b4a7594c8f43f9b73e1f0.png