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?
