了解 NASM 中 Linux x86_64 Syscall 的实现

如何解决了解 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。大多数时候使用一个好的标准是一个好主意，但任何“明显特殊”的函数当然可以使用一个特殊的约定。