[parisc-linux] signal.c, etc

[parisc-linux] signal.c, etc

[David Huggins-Daines]

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)

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.

(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.

(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...

-- 
David Huggins-Daines		-		dhd@eradicator.org

Re: [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