64位linux 系统调用,在i386和x86-64上UNIX和Linux系统调用的调用约定是什么

小编典典

有关以下任何主题的更多信息，请阅读：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

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”的问题”)

这是此部分的代码段：

用户级应用程序用作整数寄存器，以传递序列％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上使用)需要%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函数调用序列” ，部分内容为：

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

如果该类是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进入哪个寄存器的规则也非常不同。

2020-06-02