Re: remote debugging a multi-threaded program with signal

[Atsushi Nemoto <anemo@mba.ocn.ne.jp>]

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