The stack doesn't need to be aligned. The x86 CPU doesn't care about alignment. Try it. Where do you get the idea that there is a requirement that RSP is aligned-to-8? There is no documentation that I can find. Every test I have tried gave me no problems or errors. Is this some new Win11 thing, or something? How would it enforce it anyway, the hardware doesn't help.

RSP can be unaligned. It won't cause any trouble until you call a Win API that uses the aligned data loads. Otherwise go for whatever RSP value you want. And the alignment is to-16 for the Win API, not to-8.

If your debugger is so buggy that is can't display your app state without using your apps stack, then get a better debugger. And if it decides to use your stack then it still doesn't need to be aligned.

Anyhow, the red zone is a non-sequitur.. It has nothing to do with sub rsp,1.

revolution like++

Actually the debugger thing is a great distraction, because a debugger can do anything it wants. It can write to the red-zone, or the green-zone, or the twilight-zone. The debugger operator can make your code do anything or everything with the debugger. How is any of it relevant to sub rsp,1? Where does any debugger require you to have RSP aligned?

None of it requires any alignment for anything. The debugger can choose to ignore RSP and write to your memory anyway. It doesn't need to use your registers values at all. And it certainly shouldn't require the app to maintain any particular values in any registers.

I note that the article Furs keeps referring to makes no mention of alignment that I can find. Maybe I missed it?

Actually if you want to use xmm registers with stack you defenetly need to align it to 16.

There are the unaligned instructions. You are not required to have any alignment.

It can be your choice to align, but it isn't an obligation.

Or do not use xmm at all ))
The reason to use aligned instructions -- performance they made for.

You can use xmm with unaligned addresses (not just the stack, but everywhere has the same requirements).

The performance is not relevant if you have unaligned addresses then you don't get to choose, use gotta the unaligned instructions. They might be less performant, you'd need to test it to know.

But, none of that is relevant to sub rsp,1. No xmm reg used in there.

I don't say that. But, also I don't see any problems to align the stack to 16 to use movdqa with it (where needed) for better performanse. If Intel made this sort of instructions that there is some reason. That why I never use movdqu. Just to keep recomendations in mind even if it makes no big difference.

Yes, of course.

Alignment has many advantages.

But for Furs to say the app will crash only because of those eight sub rsp,1, is wrong. While alignment is desirable, it isn't compelled.

App will defenetly crash where aligned instructions used for unaligned data. We can manage that exeptions too of course, but this is failure situation.

Any way, windows programming means winapi, that needs alignment for it's own mechanics, so we need to prepare the stack without any choise.
App starts unaligned, because the call used to get into that eats 8 bytes as return address.
There is no matter how exactly we align it to 16 even if add rsp,8 We just erase normaly return address. Sometimes I do that to return few calls back at once. So sub rsp,1 eight times is only one terrible way to do the same job as we can use some more elegant instructions.

Thankfully there are very few of these instructions. AFAIK only a subset of the SSE/AVX data moves have this "problem".

And un-thankfully Win API uses those same aligned-only data moves so crashing one's app is easy to do whenever calling one of them.

But sub rsp,1 is not one of those aligned only instructions, neither are push or pop. Or any of the usual mov, add, sub, xor, etc. using the GPRs to/from memory.

The stack isn't special to require to-8 alignment that I am aware of. I wish Furs would show us where this is an actual requirement within an x86 CPU.

Anyone sane will assume the stack is aligned to at least 8 on 64-bit, so you can crash other people's code (debugger in this case). To be honest, I wouldn't deem it its fault considering that you wrote a time bomb in the first place.

Still no mention of the rsp == NULL thing, so much for using it as GPR eh?

Why does your debugger crash? I think your debugger is broken. Get a new one.

A debugger won't use the apps RSP. Do you know how a debugger modifies memory in the target? It certainly doesn't use mov [rsp], value. It calls the OS to transfer a section of memory from it's address space, to the targets address space. With byte granularity. If the memory is not mapped the OS simply returns a failure code. There is no crash. Well there should be no crash unless your debugger is really terrible.

Also, RSP == NULL is fine (any value is fine). Nothing goes wrong. You need to follow certain restrictions of course. No call/ret/push/pop or exception catching of course. But otherwise a debugger will be fine. It won't care. The OS will be fine, it won't care. If you can crash a debugger or your OS by simply changing your RSP then your debugger is crap, and your OS is neither reliable or secure.

The only reason I know of for a debugger to modify target memory is if the user tells it to. Otherwise there is no purpose for it. And there are no alignment requirements anyway, it is just a buffer transfer. Alignment requirements simply don't exist. Show us the documents stating such requirements.

So far you have shown no evidence of your claim that RSP in one app affects anything else. Please post some evidence. Prove your claim.

An app is not required to maintain a valid RSP.

So what happens in the second example with the vectored exception handler when rsp == NULL?

(btw a library you imported, library.dll, installed one globally)

I already said that if you want to catch exceptions then you need a stack.

If your app asks for them, then the OS delivers. If your app asks for them, then make sure you can receive them. The onus is on you. But that won't affect any other process or task in the system. All that happens is your app crashes. No big deal, you messed up by asking for exceptions and them not giving the OS a place for them.

ETA: There are no docs I can find that say the exception space must be alignment to any particular value.

An app is not required to maintain a valid RSP.

The point is that you may not ask for them yourself, but some other component will. Note that the other component will make sure it's as transparent as possible for your app, because it clearly doesn't expect you to use an invalid rsp, so without that your code wouldn't even know any exception occurred (which is fine).

So please stop advocating time bombs.

The only time you should be allowed to do such hacks would be when you develop the low-level system in the first place (for example, Wine on Unix, since it controls all exceptions itself).

You have failed to show how an unaligned stack from sub rsp,1 will ever crash anything.

Show you proof. Where is the proof?

I wrote some code. I encourage everyone to try it.

Does your system die? Does the app die? Does your debugger die?

Run it. It will takes a few seconds before exiting. Move your mouse. Browse the Internet. Do normal stuff.

It all works, right?

Change times 20 nop to times 20 or rcx, 0.
Nothing will change, but it's more pleasant to read.

Okay. But using times like that would fail. I hope the alternative change I made instead is acceptable.