32位x86组件中堆栈对齐的责任
我试图清楚地了解谁(调用方或被调用方)负责堆栈对齐。64位汇编的情况很清楚,它是由 caller进行的 。
参考系统V AMD64 ABI,第3.2.2节 堆栈框架 :
输入参数区域的末尾应在16(如果在堆栈上通过__m256,则为32)字节边界对齐。
换句话说, 应该 安全地假设,对于被调用函数的每个入口点:
16 | (%rsp + 8)
保持(额外的八个是因为call
隐式将返回地址压入堆栈)。
在32位世界中的外观(假设cdecl)?我注意到使用以下构造gcc
将对齐方式 放置 在调用的函数 内 :
and esp, -16
这似乎表明,这是 被叫方的 责任。
更清楚地说,请考虑以下NASM代码:
global mainextern printf
extern scanf
section .rodata
s_fmt db "%d %d", 0
s_res db `%d with remainder %d\n`, 0
section .text
main:
start 0, 0
sub esp, 8
mov DWORD [ebp-4], 0 ; dividend
mov DWORD [ebp-8], 0 ; divisor
lea eax, [ebp-8]
push eax
lea eax, [ebp-4]
push eax
push s_fmt
call scanf
add esp, 12
mov eax, [ebp-4]
cdq
idiv DWORD [ebp-8]
push edx
push eax
push s_res
call printf
xor eax, eax
leave
ret
在调用之前是否需要对齐堆栈scanf
?如果是这样,那么%esp
在将这两个参数推为scanf
as 之前,这需要减少四个字节。
4 bytes (return address)4 bytes (%ebp of previous stack frame)
8 bytes (for two variables)
12 bytes (three arguments for scanf)
= 28
回答:
如果您查看其他任何函数的代码源,除非您拥有带有alignas(32)
或的局部语言,否则您将看不到它。
GCC只是采取了一种防御性的方法-m32
,不假设main
使用正确的16B对齐堆栈来调用该方法。还是从当初-mpreferred-stack-
boundary=4只是一个好主意,而不是法律而留下的特殊待遇。
多年以来,i386 System V ABI一直保证/要求ESP + 4在功能上进行16B对齐。(即,ESP必须 在 CALL指令 之前 对齐16B
,因此堆栈上的args从16B边界开始。这与x86-64 System V相同。)
ABI还保证新的32位进程以在16B边界上对齐的ESP开始(例如_start
,在ELF入口点,ESP指向argc,而不是返回地址),并且glibc
CRT代码保持该对齐。
就调用约定而言,EBP只是另一个保留呼叫的寄存器。但是,是的,编译器的输出-fno-omit-frame-pointer
确实push
ebp要先于其他保留呼叫的寄存器(例如EBX),因此保存的EBP值会形成一个链表。(因为mov ebp,
esp在完成该推送之后,它还负责设置帧指针。)
也许gcc是防御性的,因为一个非常古老的Linux内核(从i386
ABI修订版之前的版本开始,当时所需的对齐方式仅为4B)可能违反了这一假设,而且这只是一条额外的指令,在运行期间存在一次流程(假设程序没有main
递归调用)。
与gcc不同,clang假设堆栈在进入main时已正确对齐。clang还[假设狭窄的args已被符号化或零扩展为32位,即使当前的ABI修订版尚未指定该行为(尚未)。gcc和clang都发出在调用方执行的代码,但仅clang取决于被调用方。这发生在64位代码中,但我没有检查32位。)
如果您有兴趣,可以在http://gcc.godbolt.org/上查看编译器输出,以获取main和main以外的功能。
前几天,我刚刚更新了x86标签Wiki中的ABI链接。
http://x86-64.org/仍然死了,似乎还没有回来,所以我更新了System V链接,以指向HJ
Lu的github repo中当前版本的PDF以及他的带有links的页面。
请注意,SCO网站上的最新版本 不是
当前版本,并且不包括16B堆栈对齐要求。
我认为某些BSD版本仍然不需要/保持16字节堆栈对齐。
以上是 32位x86组件中堆栈对齐的责任 的全部内容, 来源链接: utcz.com/qa/419716.html