[parisc-linux] signal.c, etc

[Richard Hirst]

Hi Dave,

On Sun, Dec 17, 2000 at 02:41:39PM -0500, David Huggins-Daines wrote:
> Hi,
> 
> Just reading through the archives, I noticed you came upon my rather
> hackish IAOQ manipulation in signal.c.
> 
> If you guys need any explanation about the intent of that code please
> ask me.  (I'm back on the parisc-linux list now, BTW)

Welcome back! Feel free to fix anything I broke.

> I freely admit that it is bogus (in fact that's why the comment was
> there), not because I didn't know which part of IAOQ was front and
> which was back, but because:
> 
> (a) There are two different signal exit paths, one from interruptions,
>     one from system calls.  This complicates things *tremendously*.
>     However, exiting from a signal handler always goes via system
>     calls, and in that case, the stored IAOQ values are meaningless.
>     I probably should have removed all the meaningless frobbings of
>     the stored IAOQ, but ... well ... time passes, you become occupied
>     elsewhere, etc.

Right, the code as was worked ok for the syscall case but broke
for the interrupt case.  The problem is that following the signal
and call to sys_rt_sigreturn, you need to return to userland either
via an interrupt return path, or a syscall return path, depending on
where you were when the signal occurred.  There is now a test in
syscall.S for __NR_rt_sigreturn in order to implement that.

> (b) I don't understand what the processor actually does when you
>     restore IAOQ on exit from an interruption.  The HP documentation
>     is not written in a particularly lucid manner.
> 
> (c) Setting iaoq_back to iaoq_front + 4 is *not* the right answer
>     because you may have taken an interruption in a branch, or an insn
>     may have been nullified, etc.

Absolutely - that was the main problem with the code as it was.
Seting iaoq_back to iaoq_front + 4 is valid if you are starting up the
signal handler, and should be ok if the singal occurred while you
were blocked on a syscall.

> (d) I had about ten billion other things to do at the time and was
>     under lots of pressure to get "more important things" working...

Sure - the current code does work for me under various test cases, but
it did take days to get to that point.

Richard