了解 NASM 中 Linux x86_64 Syscall 的实现

问题描述

我使用 linux 内核作为我的“操作系统”(这只是一个游戏)的基础。显然,我使用系统调用与内核进行交互,例如输入、声音、图形等。因为我在这个系统上没有链接器来在 <sys/syscall.h> 中使用预定义的包装器,所以我在 NASM asm 中为 C 使用了这个系统调用包装器:

global _syscall
_syscall:
  mov rax,rdi 
  mov rdi,rsi
  mov rsi,rdx
  mov rdx,rcx
  mov r10,r8
  mov r8,r9
  mov r9,[rsp + 8]
  syscall
  ret

我了解基于 System V 调用约定使用的寄存器。但是,我不明白最后一行 mov r9,[rsp + 8]。我觉得这与返回地址有关,但我不确定。

解决方法

第 7 个参数在 x86-64 System V 的堆栈上传递。

这是将第一个 C arg 放入 RAX,然后将接下来的 6 个 C args 复制到内核系统调用调用约定的 6 个 arg-passing 寄存器。 (类似函数,但使用 R10 而不是 RCX)。


craptastic glibc syscall() 函数存在的唯一原因 / 以这种方式编写是因为无法告诉 C 编译器有关自定义调用约定的信息,其中 arg 也在 RAX 中传递.这个包装器使它看起来就像任何其他带有原型的 C 函数一样。

处理新的系统调用很好,但正如您所指出的那样效率低下。如果您想要更好的 C 语言,请为您的 ISA 使用内联 asm 宏,例如https://github.com/linux-on-ibm-z/linux-syscall-support/blob/master/linux_syscall_support.h。内联 asm 很难,而且从历史上看,一些 syscall1 / syscall2(每个参数数量)宏缺少诸如 "memory" clobber 之类的东西来告诉编译器指向内存也可能是一个输入或输出。那个 github 项目是安全的,并且有各种 ISA 的代码。 (一些遗漏的优化,比如可以使用虚拟输入操作数而不是完整的“内存”破坏......但这与 asm 无关)


当然,如果您使用 asm 编写,您可以做得更好:

只需将 syscall 指令直接与正确寄存器(RDI、RSI、RDX、R10、R8、R9)中的参数一起使用,而不是具有函数调用约定的 call _syscall。这比仅仅内联 syscall 指令更糟糕:使用 syscall,您知道除了 RAX(返回值)和 RCX/R11(系统调用本身使用它们在内核代码之前保存 RIP 和 RFLAGS)之外,寄存器是未修改的运行。)而且将 args 放入函数调用寄存器所需的代码与 syscall 相同。

如果您确实想要一个包装函数(例如,在之后的 cmp rax,-4095 / jae handle_syscall_error 并且可能设置 errno),请使用内核期望的相同调用约定,因此第一条指令可以是 syscall,并不是所有的 args 都是 1 的愚蠢改组。

asm 中的函数(您只需要从 asm 调用)can use whatever calling convention is convenient。大多数时候使用一个好的标准是一个好主意,但任何“明显特殊”的函数当然可以使用一个特殊的约定。