Did the UEFI Specification make a mistake?

[wishedtobe]

According to https://uefi.org/specs/UEFI/2.10/02_Overview.html,

The registers RBX, RBP, RDI, RSI, R12, R13, R14, R15, and XMM6-XMM15 are considered nonvolatile and must be saved and restored by a function that uses them.

But obviously it didn't. Their values change after calling the EFI_BOOT_SERVICES. Is it the mistake of the author of the Specification, the programmer of the EDK2, or me?

[wishedtobe]

The error was caused by the callee dumping the register parameters into their shadow space, which I had not allocated. I still wonder why I should always reserve 0x20 bytes for the function.

[Octocontrabass]

I still wonder why I should always reserve 0x20 bytes for the function.

Because Microsoft says so. UEFI follows Microsoft's x64 ABI, and Microsoft's x64 ABI requires you to reserve that space on the stack for every function you call.

[zaval]

It's called conformance to calling convention. Even if it came from GNU/Stallman, you should conform to it. But, and the specification tells this, you should conform to the CC only on the calling UEFI services boundary. For everything internal, you can use whatever "better in your haughty opinion" CC you want. As of practical reasons why to have a shadow space, one example is when one of the parameters, passed in a register, is taken address of inside of the callee.

To the author, Judging by that couple of topics tone, you have that "I know better" beginner attitude. For this case, a friendly advice - when after launching your bad4ss assembly written next gen world dominance Sygma OS and instead of feeling the enlightenment from the 4th dimension, you experience a bunch of poop thrown in your shocked face and next you don't know how it's possible and "if it's the spec/implementation is so bad or me", the answer is "no bunny at all, always no bunny at all" "it's me, it's always me". It'll help.