内联汇编，x86 中的红色区域？

Question

Does the red zone exist in x86 ? And even if not, can you explain to me by AMD64 ?

Where is the red zone ? WIKI: "the red zone is a fixed-size area in a function's stack frame below the current stack pointer" "current stack pointer": the meaning this area (128 bytes if i understand) always below of the updated stack pointer no distance ? or we have from the start some distance between, and this distance get closer and closer when i sub the esp ?

Should I give importance to the red zone ? always when i sub the esp ? like in push or call function or create locals (caller callee) ?

If I create local variables I will get to the red zone ? and is it dangerous ? (leaf/not leaf functions)

Does it matter if I call a leaf/not leaf function ?

To avoid this area should I do: sub esp, 128 ? and if yes wen ? before each sub the esp ?

#include <stdio.h>

int main() {
    int x = 5, y, z;
    // push
    __asm {
        sub esp, 4 // allocate cell on the stack (allocate static memory) 
        // we cant put 2 addresses on the address bus  (we cant do: mov memory, memory)
        mov eax, dword ptr [x] // save value of x on eax 
        mov [esp], eax         // insert to the allocated cell value of eax (5 from x) 
    }
    // peek
    __asm {
        mov eax, [esp] // the value of what is at the top of the stack
        mov dword ptr [y], eax // copy to y
    }
    printf("y = %d\n", y);
    // pop 
    __asm {
        mov eax, [esp] // the value of what is at the top of the stack
        mov dword ptr[z], eax // copy to z
        add esp, 4 // deallocate cell on the stack (deallocate static memory) 
    }
    printf("z = %d", z);
    return 0;
}

or like this:

#include <stdio.h>

void f(int x) {
    printf("%d\n", x);
}

void g() {
    int x = 5;
    f(x);
}

int main() {
    __asm { 
        mov eax, 3
        push eax
        call f 
        add esp, 4
    }
    __asm { call g }
    return 0;
}

Answer 1

No 32-bit x86 calling conventions use a red-zone, and MSVC can't target the x86-64 convention that does (AMD64 System V, used on all non-Windows systems).

Since you use push eax (and stack args at all), your code can only compile for 32-bit mode, so you don't need to worry about a red-zone. That's true even if you were compiling with clang -fasm-blocks eg for Linux to allow asm{} syntax, instead of with MSVC or clang-cl for Windows.

---

If you were writing different code with x86-64 64-bit registers, for a non-Windows OS with clang -fasm-blocks or with normal GNU C inline asm (like asm("instructions" : "+r"(x) : "r"(y) : "rax") ), then you would need to worry about calling functions (or using the stack at all) from inside inline asm.

For that, see Calling printf in extended inline ASM for how to skip past the red-zone before using the stack, and how to declare clobbers on all the call-preserved registers.

Unfortunately there's no way to tell GCC/clang that you want to clobber the red-zone, so unless you build that with with -mno-red-zone , you need to work around it.

• Inline assembly that clobbers the red zone
• How do I tell gcc that my inline assembly clobbers part of the stack?

Answer 2

I believe the ownership of a red zone belongs to the currently running function. So, the red zone is there for the currently running function to use without additional stack adjustment.

Calling another function effectively gives control to red-zone memory to the callee — though the "red zone" will shift if the call operation pushes. Once the callee returns to the caller, the caller gets back ownership of the red zone, but cannot expect data in the red zone to be the same: the red zone is not preserved by a call — the caller may have used some stack space below the stack pointer via pushing/decrementing or without pushing (ie the red zone). (If a function wants call-preserved memory it must move the stack pointer to claim some.)

If a function chooses to use the red zone, then it must manage the data it places there. Calling another function will transfer the red zone to the callee; the caller gives it up.

So, you can use the red zone, also push as needed, also make a function call, but you'll have to follow the rules in that as much as a callee inherited a red zone, when the callee makes a call it becomes the caller and a new callee has the red zone.

Because the callee owns the red zone, there is no need to avoid it. You can simply use the memory, or push (or otherwise decrement the stack pointer) to claim some non-red zone memory which automatically and by definition moves the red zone.

---

From the discussion in comment below, Mgetz and PeterCordes inform us that the red zone size is guaranteed to callee's, by the ABI and allows for user mode signal handlers to be run on the same thread as currently executing — to avoid conflicts with the stack space, such user mode signal handlers will side step the red zone while sharing the same stack (not to mention preserving all register they use).

---

It is also possible that if you use stack space too far below the stack pointer, you may get segmentation fault or other error. Moving the stack pointer is the proper way to inform the operating system that you want more stack space. However, the ABI guarantees at least the red zone size of memory below the stack pointer will be accessible without such fault.

Answer 3

@Peter Cordes even this code in 32bit will work good ? (not worry red zone even its callee)

    #include <stdio.h>

int sum2(int num1, int num2) {
    int sum;
    printf("num1: %d\nnum2: %d\n", num1, num2);
    __asm {
        mov eax, dword ptr [num1]
        add eax, dword ptr [num2]
        mov [sum], eax
    }
    return sum;
}

int main() {
    int num1 = 2, num2 = 3, sum;
    __asm {
        mov eax, num2
        push eax
        mov ecx, num1
        push ecx
        call sum2
        mov [sum], eax
        add esp, 8
    }
    printf("sum %d ", sum);
    return 0;
}