Re: [PATCH] Cygwin: exceptions: Fix AArch64 non-incyg signal handling

Hi Jon!

> Right. So I think I understand how this problem manifests when 
> interrupting a leaf function, but I wonder if you could go into a bit 
> more detail about how it occurs inside sigfe? 
Sigfe only saves LR on the cygtls stack late into the function, so if a 
signal arrives prior to it (while testing, this usually occurred when 
it's trying to get the stacklock), then sigdelayed will set LR to where 
it was in sigfe, and sigfe stores this instead of the original LR. This 
leads to sigbe jumping back into the middle of sigfe with an already 
popped stack, and the program crashing when it tries to branch to a 
garbage address on the stack (the address of the function sigfe/sigbe 
was supposed to wrap not being read correctly due to the popped stack).
> One concern I have is that this adds a single CONTEXT.
>
> I'm not entirely sure about the situations in which nested signal 
> interrupts can occur. Is that something you considered? Is there 
> reason to believe that can't happen in these circumstances? 

When submitting the patch I remembered considering this, but now that I 
took a second look at it and made a quick test scenario (nested SIGUSR1, 
SIGUSR2 and SIGTERM signals coming from a forked process), it didn't 
seem to work correctly. Thanks for noticing it, I'll try coming up with 
a solution.

> I wonder if there's a possible implementation where we maintain a 
> stack of (lr, pc) tuples, and then exit by rotating those onto the top 
> of the stack frame and popping them both?

I will take your suggestion into consideration, however 
RtlRestoreContext will still need to be used in some form, we can't 
avoid clobbering any other way. We also cannot forget about the other 
registers that still need to be backed up somewhere.

> (It might also be worthwhile looking at the aarch64 implementation of 
> RtlRestoreContext - since it must know how to restore all registers 
> without clobbering any of them - which is exactly what we want to do 
> in sigdelayed?) 

I looked at its internals, and it uses NtContinue to restore them, which 
is a syscall (svc 0x43), so unfortunately it most likely does something 
we can't do in user-mode.

Best regards,
Máté Dimand