tracing through sig handlers
Hi Alan,
If I do this:
Index: arch/parisc/kernel/signal.c
===================================================================
RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/signal.c,v retrieving revision 1.37
signal.c +2 -0
@@ -260,6 +260,8 @@/* regs->iaoq is undefined in the syscall return path */ err |=__put_user (regs->gr[31 ], &sc->sc_iaoq[0 ]); err |=__put_user (regs->gr[31 ]+4 , &sc->sc_iaoq[1 ]); + err |=__put_user (regs->sr[3 ], &sc->sc_iasq[0 ]); + err |=__put_user (regs->sr[3 ], &sc->sc_iasq[1 ]);#if DEBUG_SIG printk ("setup_sigcontext: iaoq %#lx/%#lx\n" , regs->gr[31 ], regs->gr[31 ]);#endif
Then I can strace my little test prog. that sends itself a signal while the signal is blocked, and then unblocks the signal.
I havn't worked out why this is only apparently necessary when a process is being traced.
It makes things better with gdb also, but not perfect. The problem now is that when you try to step out of the signal handler the program under test just runs on without stopping. Previously it would have crashed with an invalid iasq[].
Richard
Quoted 2 lines · Richard Hirst
I havn't worked out why this is only apparently necessary when a process is being traced.
I'm not even going to attempt to figure out why. :-) Perhaps one of te kernel gurus can shed some light.
Quoted 3 lines
It makes things better with gdb also, but not perfect. The problem now is that when you try to step out of the signal handler the program under test just runs on without stopping.
gdb is still confused about signal handler frames, and I haven't managed to fix that today. Too many other fires to fight.
Alan
Signature · 1 line
Linuxcare