Linux ARM系统调用过程分析(一)——Linux编程中的API函数和系统调用的关系

╰+哭是因爲堅強的太久メ 2022-09-17 03:19 266阅读 0赞

# Linux ARM系统调用过程分析(一)——Linux编程中的API函数和系统调用的关系 #

备注：  
  1. Kernel版本：5.4  
  2. 使用工具：Source Insight 4.0

### 文章目录 ###

*  Linux ARM系统调用过程分析(一)——Linux编程中的API函数和系统调用的关系
 *   *  前言
     *   *  系统API
         *  系统调用
         *  两者关系
     *  系统调用号
     *  参数传递

## 前言 ##

### 系统API ###

**API：（Application Programming Interface,应用程序编程接口）**  
  指的是我们用户程序编程调用的如：open(), read(), write(), malloc(), free()之类的调用的是glibc库提供的库函数。API直接提供给用户编程使用，运行在用户态。 我们经常说到的POSIX（Portable Operating System Interface of Unix）是针对API的标准，即针对API的函数名，返回值，参数类型等。POSIX兼容也就指定这些接口函数兼容，但是并不管API具体如何实现。

### 系统调用 ###

通过软中断或系统调用指令向内核发出一个明确的请求，内核将调用内核相关函数来实现（如：sys\_open(), sys\_read(), sys\_write(), sys\_fork()）。用户程序不能直接调用这些sys\_open, sys\_read, sys\_write等函数。这些函数运行在内核态。

### 两者关系 ###

通常API函数库（如glibc）中的函数会调用封装例程，封装例程负责发起系统调用（通过发软中断或系统调用指令），这些都运行在用户态。内核开始接收系统调用后，cpu从用户态切换到内核态（cpu处于什么状态，程序就叫处于什么状态，所以很多地方也说程序从用户态切换到内核态，实际是cpu运行级别的切换，通常cpu 运行在3级表示用户态，cpu 运行在0级表示内核态），内核调用相关的内核函数来处理再逐步返回给封装例程，cpu进行一次内核态到用户态的切换，API函数从封装例程拿到结果，再处理完后返回给用户。

但是API函数不一定需要进行系统调用，如某些数学函数，没有必要进行系统调用，直接glibc里面就给处理了，整个过程运行在用户态。

所以作为我们编写linux用户程序的时候，是不能直接调用内核里面的函数的，内核里面的函数位于进程虚拟地址空间里面的内核空间，用户空间函数及函数库都处于进程虚拟地址空间里面的用户空间，用户空间调用内核空间的函数只有一个通道，这个通道就是系统调用指令，所以通常要调用glibc等库的接口函数，glibc也是用户空间的，但glibc自己实现了调用特殊的宏汇编系统调用指令进行cpu运行状态的切换，把进程从用户空间切换到内核空间。

**用户态函数执行全过程（这里只讲需要进行系统调用的函数）**  
![请添加图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5qWT5r2H5r2H_size_20_color_FFFFFF_t_70_g_se_x_16]

用户态xyz()函数，内核最终一般会调用形如sys\_xyz()的服务例程来处理（不过也有一些例外，这里暂时不考虑）。

函数xyz()是直接提供给用户编程使用的。图中“**SYSCALL**”,“SY\*\*\*IT”表示真正的汇编指令（汇编指令具体调用的是哪个暂时不关心，我们只需在此关注发起和退出了一个系统调用）。  
  发起系统调用：xyz()函数执行的过程中会执行SYSCALL汇编指令，此指令将会把cpu从用户态切换到内核态。SYACALL汇编指令中会包含将要调用的内核函数的系统调用号和参数，内核在上图系统调用处理程序中去查一个 **sys\_call\_talbe** 数组来找到这个系统调用号对应的服务例程（如sys\_xyz()）函数的地址，然后调用这个地址的函数执行。（这里glibc里面的系统调用号和内核里面的系统调用号必须完全相等，当然，这是约定好的）。

系统调用返回：服务例程（如sys\_xyz()）函数返回值一般返回正数和0表示系统调用成功结束，而负数表示一个出错条件。紧接着SY\*\*\*IT退出系统调用，此指令将cpu从内核态切换到用户态，glibc针对系统调用返回值如果出错则需要设置好errno（**通常在c库头文件/usr/include/errno.h中**），然后返回一个值做为glibc封装例程的返回值（**如xyz()的返回值**）。这里errno是libc自己用来定义的出错码，不一定是最后gblic封装例程的返回值。

## 系统调用号 ##

arm-linux系统调用号和系统调用实现函数位置  
系统调用序号：arch/arm/include/generated/uapi/asm/unistd-common.h  
对应了的文件：kernel/include/asm-generic/unistd.h  
可以查找关键字SYSCALL\_DEFINE因为include/linux/syscalls.h中包含了系统调用的统一定义

#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
    #define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
    #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
    #define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
    #define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
    #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
    
    #define SYSCALL_DEFINE_MAXARGS	6

//arch/arm/include/generated/uapi/asm/unistd-common.h
    #define __NR_restart_syscall (__NR_SYSCALL_BASE + 0)
    #define __NR_exit (__NR_SYSCALL_BASE + 1)
    #define __NR_fork (__NR_SYSCALL_BASE + 2)
    #define __NR_read (__NR_SYSCALL_BASE + 3)
    #define __NR_write (__NR_SYSCALL_BASE + 4)
    #define __NR_open (__NR_SYSCALL_BASE + 5)
    #define __NR_close (__NR_SYSCALL_BASE + 6)
    #define __NR_creat (__NR_SYSCALL_BASE + 8)
    #define __NR_link (__NR_SYSCALL_BASE + 9)
    
    // ......
    
    #define __NR_mlock2 (__NR_SYSCALL_BASE + 390)
    #define __NR_copy_file_range (__NR_SYSCALL_BASE + 391)
    #define __NR_preadv2 (__NR_SYSCALL_BASE + 392)
    #define __NR_pwritev2 (__NR_SYSCALL_BASE + 393)
    #define __NR_pkey_mprotect (__NR_SYSCALL_BASE + 394)
    #define __NR_pkey_alloc (__NR_SYSCALL_BASE + 395)
    #define __NR_pkey_free (__NR_SYSCALL_BASE + 396)
    #define __NR_statx (__NR_SYSCALL_BASE + 397)
    #define __NR_rseq (__NR_SYSCALL_BASE + 398)
    #define __NR_io_pgetevents (__NR_SYSCALL_BASE + 399)

## 参数传递 ##

在发起系统调用前，r7寄存器里面存储了系统调用号。如用户程序fork()函数，glibc 发出**svc 0**指令前，r7寄存器就会设置好内核的sys\_fork函数对应的系统调用号，这是glibc里面的封装例程会自动设置好的，程序员无需关心。

有些系统调用可能调用很多参数（除了系统调用号之外），普通c函数的参数传递是通过把参数值写入活动的程序栈（用户态栈或者内核态栈）实现的。因为系统调用是一种跨用户态和内核态的特殊函数，所以这两个栈都不能用。在发出系统调用之前，系统调用的参数写入了cpu的寄存器（如glibc去写好这些寄存器），然后发出系统调用之后，而在内核调用服务例程（如sys\_fork()服务例程）之前，内核再把存放在cpu中的参数拷贝的内核态的堆栈中（因为sys\_fork只是普通的c函数，前面说过普通c函数的参数传递是通过把参数值写入活动的程序栈（用户态栈或者内核态栈）实现的）。内核为什么不直接把用户态的栈拷贝到内核态的栈而要去通过寄存器来传呢？  
首先，同时操作两个栈是比较复杂的，其次，寄存器的使用使得系统调用处理程序的结构与其它异常处理程序的结构类似。

使用寄存器传递参数，必须满足两个条件：  
每个参数的长度不能超过寄存器的长度（比如寄存器长度32位，那参数长度就不能超过32位）；

第一个条件总能成立，因为POSIX标准规定，如果寄存器里面装不下那个长度的参数，那么必须改用参数的地址来传递。  
第二个条件有的系统调用参数大于4个（**标准过程调用约定使用r0～r3来传递参数，其余的参数压入栈中**），这种情况下，必须用一个单独的寄存器执行进程地址空间的这些参数所在的一个内存区。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5qWT5r2H5r2H_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/b9db94c7889146bcaa95388a51a81cba.png