Re: remote debugging a multi-threaded program with signal

Atsushi Nemoto
2004-03-05T02:25:07Z

>>>>> 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?