Date: Thu, 11 May 2000 22:18:53 +0200 (CEST)
From: Robert de Vries <[EMAIL PROTECTED]>
What I observe when I run a test program with a timer sending SIG33
(SIGRTMIN+1), is that after the signal has been passed through gdb it is
transformed to SIGRTMIN.
I configured gdb as follows:
handle SIG33 pass print nostop
And the result is:
Program received signal SIG33, Real-time event 33.
1.000385000: siginfo dump: si_signo: 32 [32], si_errno: 0,
si_value: int=1234 ptr=0x4d2 si_code: SI_USER, si_pid: 2799, si_uid: 500
Without GDB:
0.999014000: siginfo dump: si_signo: 33 [33], si_errno: 0,
si_value: int=1234 ptr=0x4d2 si_code: SI_TIMER, timer id: 0
Two changes:
* Signal nr 33 -> 32
* Signal source SI_TIMER -> SI_USER
I guess we are looking at a GDB problem here. The problem is that as soon
as GDB catches the signal it re-raises it with different
properties. Especially changing the signal nr is bad. The program never
receives the right signal and will exit unless a handler for SIGRTMIN is
present.
I believe the signal number problem is already fixed. The fix will be
in the upcoming GDB 5.0 release. A release candidate can be found in the
GDB snapshots directory (see http://sourceware.cygnus.com/gdb for more
info). It would be great if you could test if the problem is indeed
fixed.
I'm not sure about the change in the siginfo. This might be a
limitation in the Linux kernel. The ptrace(2) interface doesn't allow
us to specify the siginfo, and I'm not sure whether the Linux kernel
actually restores the siginfo if we continue it with the signal that
was trapped by the debugger. Or are you debugging a multithreaded
application? In that case there is some hackery that GDB has to do to
work around Linux's limited thread support. In both cases it will be
pretty hard to fix this, and probably impossible to fix without
additional kernel support. I don't see this happening in the future,
unless someone contributes a good solution.
Mark
