Attention is currently required from: Julius Werner, Paul Menzel.
Subrata Banik has posted comments on this change by Subrata Banik. ( https://review.coreboot.org/c/coreboot/+/83036?usp=email )
Change subject: libpayload/x86: Extend exception handling to x86_64 architecture ......................................................................
Patch Set 13:
(1 comment)
Patchset:
PS8:
[Subrata] I saw RCX still holds the old value correctly while existing from exception handler (irtq) although I missed to use pop old_rcx over pop %rcx. I believe that is due to restoring %rcx with old value (old_rcs) prior existing from exception.
Right, but it's when you _change_ those values through GDB that you would see the problem (because the value would be updated in the exception_state struct but not in old_rcx). You need to use GDB to stop the program, then write something like `set $rcx = 0x12345678` in the GDB console, use `info registers` to confirm that the change took hold, then step through another instruction (one that shouldn't touch RCX), and then use `info registers` again to confirm it still got 0x12345678 and not 0x03020100 again.
[Subrata] yes, I have verified following above steps. the value holds by the RCX is aligned to our expectation.
Anyway, with the fixed code it should work now but it would be good to double-check. If you use GDB to call a function (e.g. `p printf("Test output %d %d %d %d\n", 1, 2, 3, 4)`), that should also be a pretty good test that should exercise a lot of the register rewriting functionality.
I have stopped into gdb and then override RCX=0x12345678 (verified using `info register`) and then call into fw_shell `do_mm` to trigger an exception. At the end of the exception, while control again came back to GDB, used `info register` to ensure that RCX still holds 0x12345678