Linux does not require shadow space

[jack]

I cringe when people brag about ChatGPT or similar writing this or that program for them, what's the point?
however, I find ChatGPT very useful for getting intelligent information, for example, in the asm examples in Linux I didn't see any shadow stack reserved when calling printf, so I asked ChatGPT two questions
does Linux require assembly programmer to reserve shadow space for external functions?

In Linux, whether you need to reserve shadow space for external functions when writing in assembly depends on the calling convention used by the system.

For **x86-64 (AMD64)** Linux systems:

- **System V AMD64 ABI** is the standard calling convention.
- Shadow space (sometimes called "home space" or "spill space") is **not** required by the System V AMD64 ABI. This is different from the Windows x64 calling convention, where a 32-byte shadow space is required for function calls.

In Linux, when calling an external function, you generally need to:

1. Ensure that the stack is aligned to a 16-byte boundary before making the `call` instruction.
2. Pass arguments according to the calling convention (registers like `rdi`, `rsi`, `rdx`, etc.).
3. Manage the stack frame if necessary (e.g., for local variables or callee-saved registers).

However, you do not need to reserve additional stack space specifically for shadow space as you would on Windows.

### Summary
- On Linux using the System V AMD64 ABI: **No shadow space reservation is needed**.
- On Windows using the x64 calling convention: **Yes, shadow space reservation is required**.

in Linux, is the stack aligned to a 16-byte boundary by default?

Yes, on Linux, the stack is aligned to a 16-byte boundary by default when a function is called. This alignment is required by the **System V AMD64 ABI** calling convention, which is the standard on x86-64 Linux systems.

### Why 16-byte Alignment?

The 16-byte alignment is important for performance reasons, particularly for SIMD (Single Instruction, Multiple Data) instructions, which often require data to be aligned to 16 bytes for optimal access. This alignment is also necessary to meet the ABI's requirements for passing certain types of data, such as vectors.

### Stack Alignment Rules

- **Caller Responsibility**: The caller is responsible for ensuring that the stack is aligned to a 16-byte boundary before making a function call. This typically means that the stack pointer (RSP) should be 16-byte aligned after the call instruction.
 
- **Callee Responsibility**: The callee can assume that the stack is 16-byte aligned when it begins executing. However, if the callee changes the stack pointer (e.g., by allocating local variables), it must ensure that the stack remains aligned before calling other functions.

### Example Scenario

If you are writing assembly code and need to make sure the stack is aligned, you might adjust the stack pointer before making a call:

```assembly
sub rsp, 8    ; Align the stack if necessary
call some_function
add rsp, 8    ; Restore the stack
```

In this example, the subtraction aligns the stack to 16 bytes, assuming it wasn't already.

If the stack pointer is already aligned and you know it (e.g., within your own functions), you don't need to make this adjustment.

now this is great news for me, I can explore assembly programming on Linux without the hassles that Windows imposes 

[zedd151]

I'm not so sure about that assertion. It just doesn't seem right to me, knowing what little I do know about 64 bit programming and the 64 bit ABI.

It should not matter what operating system is used, it is a microprocessor requirement from my understanding... irrespective of operating system used, imho.

That being said, I am a 32 bit guy - exclusively.

[NoCforMe]

I'm the guy merrily driving the 32-bit vehicle right past the 64-bit guy who's hopelessly bogged down in the mud, spinning his wheels ...

[jack]

NoCforMe
I still remember the DOS die-hard guys, guys that were stuck in the past unwilling to move forward, you remind me of them.

[NoCforMe]

No, Jack, for me, 64-bit programming would be a step backwards. Why? Because, mainly, I don't need it!
Too many people here (mostly n00bs) assume that if 32 bits is good, 64 bits must be better. But if 64-bit programming is much more a pain in the ass than 32-bit (and it is, at least until you get farther out on the learning curve), and if it's really not necessary for programmers like me who have sufficient speed and address space with 32 bits, then why bother?

Not at all the same as the move from DOS to Windows/flat address space/16 bits to 32 bits.

[mineiro]

You need check systemV ABI, the start point to migrate to linux:
https://gitlab.com/x86-psABIs/x86-64-ABI

Similarities that I seen between both O.S. are stack alignment to 16 (before a call instruction), structures aligned to 8.
Function parameters differ, windows uses with rcx,rdx,r8,r9, stack for general purpose registers. In linux, this differs to:
call  function_name rdi,rsi,rdx,rcx,r8,r9, stack, ...
Abi also say about using native functions (like int 21 from ms-dos) but using syscall's.
syscall  (rax) rdi,rsi,rdx,r10,r8,r9
There's a register preservation, rbx,rbp, r12 to r15 that should be preserved inside your procedure/rotine/function if you modify these registers. I use a lot these registers to hold variables because they values are preserved (not modified) when calling external library function.

now this is great news for me, I can explore assembly programming on Linux without the hassles that Windows imposes 

Welcome, we can join knowledge.

[NoCforMe]

now this is great news for me, I can explore assembly programming on Linux without the hassles that Windows imposes

Aren't you just trading the hassles that Windows imposes for the hassles that Linux imposes? Is one really better than the other (so far as the ABI is concerned)?

[jack]

thanks mineiro