我正在学习ATT ASM，所以我还在阅读Linux AMD64 ABI，并且我注意到计算机系统：程序员的视角（CSAPP）具有相同的内容（堆栈框架布局）。我发现堆栈框架布局不同，它们的返回地址分为不同的位置。 CSAPP ASM代码似乎在Intel X86_X64上设置（这是IA-64？）。
以下是AMD64堆栈框架布局，
下面是CSAPP堆栈框架布局。
我假设Intel X86_x64是IA-64，所以我检查，在图片下找到。
，我发现CSAPP描述了数据传输。
当一个函数具有六个以上的积分参数时，其他参数将在堆栈上传递。假设程序p调用n个积分参数调用过程q，以便n＆gt; 6。然后，P的代码必须分配一个带有足够存储的堆栈框架，用于参数7至n。
无法对应，我不太了解为什么会有区别。也许我发现了错误的文档。
更新：
我知道AMD64不是IA-64，也知道IA-64是Intel的Itanium。在提出问题之前，我读了一些Wiki。我认为CSAPP在Linux环境中，因此我应该阅读Linux ABI，但是官方文档提供的架构列表不包含Intel X86_64，因此我假设Intel X86_X64是IA-64。抱歉，我是新手。我想知道CSAPP的堆栈框架布局，从哪个体系结构使用，我认为我将在Unix型工作中工作，因此我应该学习哪些体系结构。
I'm learn ATT asm, so I'm also reading Linux amd64 ABI, and I notice Computer Systems: A Programmer's Perspective (CSAPP) has the same content (stack frame layout). I found the stack frame layout is different, their return address is divided into difference places. CSAPP asm code seems to set up on Intel x86_x64 (is this IA-64?).
Below is amd64 stack frame layout, 3.2.1 Registers and the Stack Frame
Below is CSAPP stack frame layout.
I assume Intel x86_x64 is IA-64, so I check Linux core IA-64 ABI, and found below picture.
And, I found the CSAPP describes data transfer.
When a function has more than six integral arguments, the other ones are passed on the stack. Assume that procedure P calls procedure Q with n integral arguments, such that n > 6. Then the code for P must allocate a stack frame with enough storage for arguments 7 through n.
No way to correspond, I don't quite understand why there are difference. maybe I found wrong documentation.
Update:
I know that amd64 is not IA-64, also know IA-64 is Intel's Itanium. I read a little bit of wiki before asking question. I think CSAPP is in Linux environment, so I should read Linux ABI, but official documentation provides architecture list doesn't contain Intel x86_64, So appear I assume Intel x86_x64 is IA-64. Sorry, I am a novice. I want to know stack frame layout of CSAPP from which architecture, I think I will work in Unix-like, so I should learn which architecture.
发布评论
评论（1）
这里最多有5个不同的呼叫约定：
系统V AMD64 ABI，其中包括红色区域。
x86_64的Linux内核ABI;这是系统v AMD64 ABI，但没有任何红色区域。
Microsoft X64调用约定；具有“阴影空间”（没有红色区域）
linux在itanium上使用的任何内容（与x86_64无关）。
以上都不是。对于纯粹的组装，您不必符合任何ABI（直到/除非您打电话给共享库或其他语言写的东西）。
“ CSAPP堆栈框架布局”没有红色区域。因此，它必须是其他可能性之一。我假设Microsoft X64调用约定是最有可能的（该图的“保存寄存器”是“影子空间”的32个字节）；由于用户空间应用程序比内核空间代码更有可能，因此80x86比iTanium更有可能，并且拥有“无呼叫约定的示意图，每个函数都可以执行自己喜欢的东西”是没有意义的。
There are up to 5 different calling conventions here:
The System V AMD64 ABI, which includes a red zone.
The Linux kernel ABI for x86_64; which is System V AMD64 ABI but without any red zone.
Microsoft x64 calling convention; which has "shadow space" (and no red zone)
Whatever Linux uses on Itanium (which has nothing to do with x86_64).
None of the above. For pure assembly you don't have to conform to any ABI (until/unless you're calling a shared library or something written in another language).
The "csapp stack frame layout" has no red zone; so it must be one of the other possibilities. I'd assume the Microsoft x64 calling convention is the most likely (where the diagram's "saved registers" are the 32 bytes of "shadow space"); as a user-space application is more likely than kernel-space code, 80x86 is more likely than Itanium, and it doesn't make sense to have a diagram for "no calling convention, each function does what it likes".