On Wed, 26 Apr 2023, Michael Schmitz wrote:
On 26/04/23 07:46, Michael Schmitz wrote:
I had thought the 030 could resume the interrupted instruction using
the information from the exception frame - and that does appear to
work in all other cases except where signal delivery gets in the way,
and it also works if moving the exception frame a little bit further
down the stack. So our treatment of the bus error exception frame
during signal delivery appears to be incorrect. Wouldn't you agree?
Inspection of the format b frame placed in the signal frame in both rt
and non-rt cases (at the time the signal handler runs) shows the
expected contents in the data output buffer, data fault address and ssw.
At that time, returning to user space with rte would correctly resume
the instruction execution. I had previously confirmed that the register
contents saved in the rt signal frame is correct also.
That is with a kernel patched similar to above patch by Finn (using an
offset of 128 or 64 instead of 256).
That means things go awry during sys_sigreturn or sys_rt_sigreturn. I'm
not sure what happens to the exception frame:
1:
| stack contents now:
| [original pt_regs address] [original switch_stack address]
| [unused part of the gap] [moved switch_stack] [moved pt_regs]
| [replacement exception frame]
| return value of do_{rt_,}sigreturn() points to moved switch_stack.
movel %d0,%sp | discard the leftover junk
RESTORE_SWITCH_STACK
| stack contents now is just [syscall return address] [pt_regs] [frame]
| return pt_regs.d0
movel %sp@(PT_OFF_D0+4),%d0
rts
... but I noticed that the sys_rt_sigreturn entry point does
SAVE_SWITCH_STACK while the sys_sigreturn entry point does not. Yet both
jump to label 1 above, so both syscalls do RESTORE_SWITCH_STACK. Hmmm.
.macro SAVE_SWITCH_STACK
moveml %a3-%a6/%d6-%d7,%sp@-
.endm
.macro RESTORE_SWITCH_STACK
moveml %sp@+,%a3-%a6/%d6-%d7
.endm
Well, that has to corrupt %a3, right?