NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Debugging threaded processes
Gentlepeople,
I'm working on adding thread debug support to gdb to handle the
kernel-based pthreads support that showed up in 5.0.
The basics are easy enough and I have that working. (This will be
submitted to the FSF GDB team.)
However, I have run into a problem in the way the kernel handles the
breakpoint signal if there are multiple running threads, at least if a
given breakpoint is hit by more than one of them (because they are both
executing the same function).
I have a tentative cause identified, but I'm not sure of the correct way
to go about fixing it.
What's happening is that the signal code (5) is written into p_xstat,
and then the LWP is stopped. Having the value in p_xstat is how
waitpid() finds the signal code so it can report that to gdb. (GDB uses
waitpid() when waiting for the debugged process to hit a break.)
Unfortunately, p_xstat is also used to carry a signal delivered from GDB
to the process (as the fourth argument of ptrace() P_CONTINUE function).
So what happens, if I correctly interpreted my debug sessions, is that
one thread hits the breakpoint, sets p_xstat to 5, calls sigswitch() to
get some other LWP scheduled. However, the LWP that's picked is one of
the other threads for the same process. It's continuing from a break,
so it calls sigchecktrace() to see if gdb gave it a signal.
sigchecktrace returns what's in p_xstat, which is 5, so a break is
delivered to the process, which kills it.
I can think of two approaches to fixing this.
1. Split apart the two uses of p_xstat into two variables: (a) the
signal being sent from the process to its parent, and (b) the signal
being sent from gdb via ptrace to the child.
2. Do something around the place where sigswitch() is called to stop all
the LWPs before calling mi_switch, so we can't get into the situation
where the very next thing that happens is that another thread of the
same process runs and picks up p_xstat.
It seems to me that (2) is the better answer. I'm not sure how to do
this, though. Any suggestions?
paul
Home |
Main Index |
Thread Index |
Old Index