signal.c, etc
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...
Signature · 1 line
David Huggins-Daines - [email protected]
Hi Dave,
Quoted 7 lines · 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)
Welcome back! Feel free to fix anything I broke.
Quoted 11 lines
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.
Quoted 7 lines
(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_backtoiaoq_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.
Quoted 2 lines
(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