输入新功能时rsp不会移动 [英] rsp doesn't move when entering new function
问题描述
当我输入C函数时，我期望在反汇编中看到如何将堆栈指针减去足够多的空间以容纳变量，但是没有；我只看到当esp仍指向ebp时如何通过ebp直接访问变量的地址.
push %rbp
mov %rsp,%rbp
movl $0x4,-0x4(%rbp)
mov $0x0,%eax
pop %rbp
retq
我必须创建许多变量并将其初始化，以使计算机认真对待它们，并查看产生了多少不必要的空间.差异真的是所使用的空间量还是其他?如果是这样， 仅当我请求大量空间时才需要通过移动rsp腾出空间吗?
x86-64 System V ABI在RSP下方有一个128字节的红色区域，可以防止异步破坏，即该功能拥有"了红色区域./p>
似乎您使用gcc -O0编译了int foo{ int x = 4; return 0; }(禁用了优化功能)，并且gcc选择将x保留在红色区域标签Wiki .)
这是红色区域的重点:将这些sub/add指令保存在叶函数中.
顺便说一句，查看未优化的代码通常是浪费时间.至少-O1更具可读性，并且-O2/-O3与您实际上应该关心的代码相关.另请参见如何删除噪声"是从GCC/clang程序集输出中获得的?.
在没有信号处理程序的程序中，整个堆栈区域都可以有效地用作红色区域.示例:代码高尔夫球扩展精度斐波那契使用esp作为数组指针，因为pop是快速而紧凑. (AFAIK，信号处理程序是唯一会异步破坏rsp下面的内存的东西).红区使编译器无需特殊的编译选项即可使用它(对于SysV ABI未定义红区的32位模式，没有这样的选项).即使没有整个程序优化，证明没有信号处理程序也可能不可行.
我只看到如何通过ebp直接访问变量的地址
不，你不知道.通过ebp进行的访问将在64位代码中出错，因为堆栈位于低4GB的地址空间之外(至少在Linux上默认为).指针是64位的，因此gcc使用rbp来访问它们.
使用地址大小的前缀在64位模式下对movl $0x4,-0x4(%ebp)进行编码将浪费代码大小，即使这没有错.
有趣的事实:在指针为32位的x32 ABI(长模式下为ILP32)中，gcc经常使用地址大小的前缀而不是额外的指令来截断寄存器中可能存在的高垃圾，并确保寻址模式以2换行^ 32，而不是超出4GB(例如，带符号位移).并非最佳地执行此操作，它默认只是愚蠢地在每指令上使用具有显式内存操作数的地址大小前缀.但是最近的补丁使它始终使用64位rsp ，甚至不对esp使用地址大小前缀.
When entering in a C function I expected to see in the disassembly how the stack pointer gets subtracted enough to make space for variables, but no; I only see how the address of variables is directly access through ebp, when esp still points to ebp.
push %rbp
mov %rsp,%rbp
movl $0x4,-0x4(%rbp)
mov $0x0,%eax
pop %rbp
retq
I had to create a lot of variables and initialize them to be taken serious by the computer and see how a lot of unneeded space was made. Was the difference really the amount of space used or something else? and if so, how is it that making room by moving rsp is only needed when I request for a lot of space?
The x86-64 System V ABI has a 128-byte red zone below RSP that is safe from asynchronous clobbering, i.e. is "owned" by the function.
It looks like you compiled int foo{ int x = 4; return 0; } with gcc -O0 (optimizations disabled), and gcc chose to keep x in the red-zone instead of adjusting rsp to "reserve" / "allocate" the stack space. (See the red-zone tag wiki for more links / info.)
This is the whole point of the red-zone: to save those sub/add instructions in leaf functions.
BTW, looking at un-optimized code is usually a waste of time. -O1 at least is more readable, and -O2 / -O3 are relevant for code that you should actually care about. See also How to remove "noise" from GCC/clang assembly output?.
In programs with no signal handlers, the entire stack region can effectively be used as a red-zone. example: code-golf extended-precision Fibonacci using esp as an array pointer because pop is fast and compact. (AFAIK, signal handlers are the only thing that will asynchronously clobber memory below rsp). The red-zone lets compilers take advantage of it without needing a special compile option (and there is no such option for 32-bit mode where the SysV ABI doesn't define a red-zone). Proving that there are no signal handlers is probably not feasible even with whole-program optimization.
I only see how the address of variables is directly access through ebp
No, you don't. Access through ebp would fault in 64-bit code, because the stack is outside the low 4GB of address space (by default on Linux at least). Pointers are 64-bit, so gcc uses rbp to access them.
Using an address-size prefix to encode movl $0x4,-0x4(%ebp) in 64-bit mode would be a waste of code size even if it didn't fault.
Fun fact: in the x32 ABI (ILP32 in long mode) where pointers are 32-bit, gcc often uses the address-size prefix instead of extra instructions to truncate possible high garbage in registers and make sure addressing modes wrap at 2^32 instead of going outside 4GB (with a signed displacement for example). Instead of doing this optimally, it defaults to just stupidly using address-size prefixes on every instruction with an explicit memory operand. But a recent patch gets it to always use 64-bit rsp instead of using address-size prefixes even for esp.
这篇关于输入新功能时rsp不会移动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
