有关以下任何主题的更多信息，请阅读：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 AssemblyTutorial中摘录了以下片段，但对此感到怀疑。如果有人可以举一个例子，那就太好了。

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

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

有一种进行32位系统调用的更快方法：使用sysenter。内核将页面的内存映射到每个进程（vDSO）中，而舞动的用户空间端sysenter则必须与内核合作才能找到返回地址。用于寄存器映射的Arg与for相同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的功能。

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

这是此部分的代码段：

1. 用户级应用程序用作整数寄存器，以传递序列％rdi，％rsi，％rdx，％rcx，％r8和％r9。
   内核接口使用％rdi，％rsi，％rdx，％r10，％r8和％r9。
2. 通过 syscall指令进行系统调用。此副本％rcx和％r11以及％rax返回值，但保留了其他寄存器。
3. 系统调用的编号必须在寄存器％rax中传递。
4. 系统调用仅限于六个参数，没有参数直接在堆栈上传递。
5. 从系统调用返回，寄存器％rax包含系统调用的结果。-4095到-1之间的值表示错误，它是-errno。
6. 仅将类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上使用）需要%esp在a之前对齐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函数调用序列” ，部分内容为：

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

1. 如果该类是MEMORY，则在堆栈上传递参数。
2. 如果类是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进入哪个寄存器的规则也非常不同。