This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: remote debugging a multi-threaded program with signal
>>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz <drow@false.org> said:
drow> I thought you said you got the same results without
drow> verbose-resume? Oh, I suppose you would; without verbose-resume
drow> it's pot-luck which thread gets the signal.
drow> If I use a pre-vCont gdb client with the current gdbserver I
drow> see:
drow> [sigtest:30016:16384]:main
drow> [sigtest:30018:16386]:func
drow> [sigtest:30016:16384]:send SIGUSR1
drow> [sigtest:30016:16384]:send SIGUSR1
Oh yes, I got the same result without verbose-reume, but I did not see
any ':sigwait 10' messages on another machine.
drow> That resumes only the thread in question. This is in
drow> target-indepenedent code and the only reason that lin-lwp native
drow> execution does not show the same problem is that it shortcuts
drow> around this code completely (see lin_lwp_wait).
You mean following code in lin_lwp_wait (lin-lwp.c:1518) ?
if (signal_stop_state (signo) == 0
&& signal_print_state (signo) == 0
&& signal_pass_state (signo) == 1)
{
/* FIMXE: kettenis/2001-06-06: Should we resume all threads
here? It is not clear we should. GDB may not expect
It shourcuts the code on "noprint" case, but not on "nostop" case. So
I suppose native execution also have this problem.
drow> Could you try this instead?
Thank you. It works well with verbose-resume.
How about when verbose-resume was disabled or unavailable? If
verbose-resume is necessary to continue with signal, gdb can warn it
for users? Or gdbserver can resume all threads on this case?
---
Atsushi Nemoto