PROSAGA码农传奇-Linux/Unix-在i386和x86-64上UNIX和Linux系统调用的调用约定是什么

我在Linux上使用GNU汇编器（气体）验证了这些。

内核接口
x86-32又名i386 Linux系统调用约定：

在x86-32中，使用寄存器传递用于Linux系统调用的参数。%eax用于syscall_number。％ebx，％ecx，％edx，％esi，％edi，％ebp用于将6个参数传递给系统调用。

返回值为in %eax。所有其他寄存器（包括EFLAGS）都保留在内int $0x80。

我从Linux Assembly Tutorial中摘录了以下片段，但对此感到怀疑。如果有人可以举一个例子，那就太好了。

如果有六个以上的参数，则 %ebx必须包含参数列表存储的内存位置-但不必担心，因为您不太可能将系统调用与六个以上的参数一起使用。

有关示例和更多内容，请参见http://www.int80h.org/bsdasm/#alternate-calling-convention。i386 Linux的Hello World的另一个示例使用int 0x80：您好，Linux系统调用中的汇编语言世界？

有一种进行32位系统调用的更快方法：使用sysenter。内核将页面的内存映射到每个进程（vDSO）中，而舞动的用户空间端sysenter则必须与内核合作才能找到返回地址。寄存器映射的Arg与相同int $0x80。通常，您应该调用vDSO，而不是sysenter直接使用。（有关链接和调用vDSO的信息，以及有关的更多信息以及与系统调用有关的所有其他信息，请参见《 Linux系统调用权威指南》sysenter。）

x86-32 [Free | Open | Net | DragonFly] BSD UNIX系统调用约定：

参数在堆栈上传递。将参数（最后一个参数先被压入）推入堆栈。然后推送一个额外的32位虚拟数据（它实际上不是虚拟数据。有关更多信息，请参见下面的链接），然后给出系统调用指令int $0x80

http://www.int80h.org/bsdasm/#default-calling-convention

x86-64 Linux系统调用约定：
x86-64 Mac OS X相似但不同。TODO：检查* BSD的功能。

请参阅《System V应用程序二进制接口AMD64体系结构处理器补编》中的“ A.2 AMD64 Linux内核约定”部分。可从ABI维护人员的存储库中的此页面链接找到最新版本的i386和x86-64 System V psABI 。（另请参见x86 标记Wiki，以获取最新的ABI链接以及有关x86 asm的许多其他好东西。）

这是此部分的代码段：

用户级应用程序用作整数寄存器，以传递序列％rdi，％rsi，％rdx，％rcx，％r8和％r9。内核接口使用％rdi，％rsi，％rdx，％r10，％r8和％r9。
通过syscall指令进行系统调用。此副本％rcx和％r11以及％rax返回值，但保留了其他寄存器。
系统调用的编号必须在寄存器％rax中传递。
系统调用仅限于六个参数，没有参数直接在堆栈上传递。
从系统调用返回，寄存器％rax包含系统调用的结果。-4095到-1之间的值表示错误，它是-errno。
仅将类INTEGER或类MEMORY的值传递给内核。
请记住，这是从ABI特定于Linux的附录中获得的，即使对于Linux来说，它的信息内容也不是规范性的。（但实际上是准确的。）

此32位int $0x80ABI 可用于64位代码（但强烈建议不要使用）。 如果以64位代码使用32位int 0x80 Linux ABI，会发生什么情况？ 它仍然将输入截断为32位，因此不适合使用指针，并且将r8-r11归零。

用户界面：函数调用
x86-32函数调用约定：

在x86-32中，参数在堆栈上传递。最后一个参数首先被压入堆栈，直到完成所有参数，然后call执行指令。这用于在Linux上从程序集调用C库（libc）函数。

i386 System V ABI的现代版本（在Linux上使用）要求%espa之前的16字节对齐call，就像x86-64 System V ABI始终需要的一样。被调用者被允许假定并使用SSE 16字节加载/存储在未对齐时发生故障。但是从历史上看，Linux只需要4字节的堆栈对齐，因此即使为8字节之类的double东西保留自然对齐的空间也要花费额外的工作。

其他一些现代32位系统仍然不需要超过4字节的堆栈对齐。

x86-64 System V用户空间函数调用约定：
x86-64 System V在寄存器中传递了args，这比i386 System V的堆栈args约定效率更高。它避免了将args存储到内存（缓存）然后再将它们重新加载到被调用方中的延迟和额外的指令。因为有更多可用的寄存器，所以这种方法行之有效，并且对于延迟和无序执行至关重要的现代高性能CPU更好。（i386 ABI很旧）。

在这种新机制中：首先，将参数划分为类。每个参数的类确定将其传递给被调用函数的方式。

有关完整的信息，请参见：系统V应用程序二进制接口AMD64体系结构处理器补充的 “ 3.2函数调用序列” ，部分内容为：

对参数进行分类后，将按以下顺序分配寄存器（从左到右的顺序）以进行传递：

如果该类是MEMORY，则在堆栈上传递参数。
如果该类是INTEGER，则使用序列％rdi，％rsi，％rdx，％rcx，％r8和％r9的下一个可用寄存器
用来按顺序将整数/指针（即INTEGER类）参数传递给汇编中任何libc函数%rdi, %rsi, %rdx, %rcx, %r8 and %r9的寄存器也是如此。％rdi用于第一个INTEGER参数。％rsi代表第二，％rdx代表第三，依此类推。然后call应该给出指示。执行时，堆栈（%rsp）必须对齐16B call。

如果有6个以上INTEGER参数，则将第7个INTEGER参数及更高版本传递给堆栈。（弹出呼叫者，与x86-32相同。）

前8个浮点args在％xmm0-7中传递，随后在堆栈中传递。没有保留呼叫的向量寄存器。（一个包含FP和整数参数的函数的寄存器总数可以超过8个。）

可变参数函数（如printf）始终需要%al= FP寄存器args的数量。

对于何时将结构打包到寄存器（rdx:rax返回时）与在内存中打包有一些规则。有关详细信息，请参见ABI，并检查编译器输出，以确保您的代码与编译器就如何传递/返回某些内容达成一致。

请注意，Windows x64函数调用约定与x86-64 System V有多个显着差异，例如，必须由调用者保留的阴影空间（而不是红色区域）和保留了呼叫的xmm6-xmm15。arg进入哪个寄存器的规则也非常不同。