[mihawk-99]

Signal handlers built against the current header read the wrong general-register slots on my firmware 12.090.001 console. The header places uc_mcontext at byte 16; the recorded signal frame places it at byte 64. Consequently, the header reads RIP at byte 176 instead of the observed byte 224.

This adds 48 reserved bytes between uc_sigmask and uc_mcontext, matching the change already used by my SDK fork. It also adds samples/test_signal_context, a small SIGILL test: an assembly helper puts a known marker in RAX and executes UD2 at a known address. The handler reads RAX and RIP through ucontext_t, then uses siglongjmp to return safely. The sample reports the observed values and fails if either is wrong.

Evidence and validation

The saved console runs and checker record firmware identity and register-marker positions. I reran that checker successfully. Separate PS5-target compile assertions match all 15 recorded positions: RDI, RSI, RDX, RCX, R8, R9, RAX, RBP, R10–R15, and RIP.

The new sample compiles and links with Clang 23.1.1 through the SDK wrapper. Its two offset assertions fail against the original header (16 versus 64; 176 versus 224) and pass against the patched header.

make -C samples/test_signal_context PS5_PAYLOAD_SDK=/path/to/patched-sdk
make -C samples/test_signal_context test PS5_PAYLOAD_SDK=/path/to/patched-sdk

Draft: I have not run this new, smaller sample on the console yet. The supporting runtime evidence is the existing 12.09 register-marker probe. The meaning of the reserved bytes, trailing context fields, other firmware, and getcontext/setcontext compatibility are not established by those measurements. Please treat this as a proposed signal-frame correction with a reproducer, not a claim that the entire context ABI is verified.

Refs #70.

[john-tornblom]

Please confirm issues on real hardware before submitting a pr