On 10/19/2026 5:11 PM, Marco Liebel wrote:
On Fri, Oct 16, 2026 at 12:08 PM Brian Cain <[email protected]> wrote:The frame that allocframe pushes is {LR, FP}, and what is scrambled is the LR word: FRAMEKEY is XOR'd into the upper 32 bits. The generated code for fFRAME_SCRAMBLE built the key from FRAMEKEY in both halves of a 64-bit value, so it scrambled FP as well. deallocframe and dealloc_return only undo the upper word, so a FP restored from a frame pushed with a non-zero FRAMEKEY was corrupt.I think the commit message is not quite right. AFAICT the error only shows up when idef-parser is used, FRAMEKEY is not 0, and allocframe is followed by dealloc_return. That also means the test doesn't cover the case that actually breaks, because it pops the frame with deallocframe. allocframe and deallocframe have the same bug, so FP comes back correct either way. Only the first check catches the bug, through the wrong FP word that allocframe stores in memory. The other checks pass with or without the fix.
fixed in v2: https://lore.kernel.org/qemu-devel/[email protected]/
