Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: gdb-patches@sources.redhat.com
Subject: Re: remote debugging a multi-threaded program with signal
Date: Fri, 19 Mar 2004 00:09:00 -0000	[thread overview]
Message-ID: <20040304222800.GA29911@nevyn.them.org> (raw)
Message-ID: <20040319000900.0qkHIYBWZdSSVVNTp8fx7c9AhfJ5fdG8PxCZoAXrr5Q@z> (raw)
In-Reply-To: <20040305.000540.59461353.anemo@mba.ocn.ne.jp>

On Fri, Mar 05, 2004 at 12:05:40AM +0900, Atsushi Nemoto wrote:
> >>>>> On Thu, 04 Mar 2004 01:06:24 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> 
> anemo> There is a program on remote-debugging a multi-threaded program
> anemo> which uses signals.  After receiving a signal (configured to
> anemo> "nostop"), the thread which receives it resumes normally but
> anemo> other threads leave stopped.
> 
> The last packet sent to gdbserver is "$vCont;C1e:402" (see gdb.output1).
> 
> gdb's info states:
> 
> `vCont'[;ACTION[`:'TID]]... -- extended resume
>      Resume the inferior.  Different actions may be specified for each
>      thread.  If an action is specified with no TID, then it is applied
>      to any threads that don't have a specific action specified; if no
>      default action is specified then other threads should remain
>      stopped.  ...
> 
> So the patcket means "continue thread 0x402 with signal 0x1e, others
> remain stopped".  Then current gdbserver's behavior is correct.  
> 
> Following the info statements, gdb should send "$vCont;C1e:402;c" to
> handle a "nostop" signal correctly?

I thought you said you got the same results without verbose-resume?
Oh, I suppose you would; without verbose-resume it's pot-luck which
thread gets the signal.

If I use a pre-vCont gdb client with the current gdbserver I see:

[sigtest:30016:16384]:main
[sigtest:30018:16386]:func
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1
[sigtest:30016:16384]:send SIGUSR1

This means that the signal is being delivered to the wrong thread,
since neither thread appears to be stopped.  Which is what I would
expect without vCont, since vCont was intended to solve this exact
problem.

GDB's behavior with threads is a little under-specified, but code to
generate the "correct" vCont packet is definitely there.  Unfortunately
it is not reached.  We get this:

Breakpoint 1, remote_vcont_resume (ptid={pid = 16386, lwp = 0, tid = 0}, step=0,
    siggnal=TARGET_SIGNAL_USR1) at /opt/src/gdb/src/gdb/remote.c:2461

i.e. the remote target was asked to resume only one thread.

Aha, here's the bug:
      /* If it's not SIGTRAP and not a signal we want to stop for, then
         continue the thread. */

      if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
        {
          if (printed)
            target_terminal_inferior ();

          /* Clear the signal if it should not be passed.  */
          if (signal_program[stop_signal] == 0)
            stop_signal = TARGET_SIGNAL_0;

          target_resume (ecs->ptid, 0, stop_signal);
          prepare_to_wait (ecs);
          return;
        }

That resumes only the thread in question.  This is in
target-indepenedent code and the only reason that lin-lwp native
execution does not show the same problem is that it shortcuts around
this code completely (see lin_lwp_wait).

Could you try this instead?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-03-04  Daniel Jacobowitz  <drow@mvista.com>

	* infrun.c (handle_inferior_event): Pass nostop signals to the
	correct thread.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.137
diff -u -p -r1.137 infrun.c
--- infrun.c	16 Feb 2004 20:49:51 -0000	1.137
+++ infrun.c	4 Mar 2004 22:27:11 -0000
@@ -1918,32 +1918,29 @@ handle_inferior_event (struct execution_
 #endif
 	}
 
+      context_switch (ecs);
+
+      if (context_hook)
+	context_hook (pid_to_thread_id (ecs->ptid));
+
+      flush_cached_frames ();
+
       /* If it's not SIGTRAP and not a signal we want to stop for, then
          continue the thread. */
 
       if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
 	{
-	  if (printed)
-	    target_terminal_inferior ();
-
 	  /* Clear the signal if it should not be passed.  */
 	  if (signal_program[stop_signal] == 0)
 	    stop_signal = TARGET_SIGNAL_0;
 
-	  target_resume (ecs->ptid, 0, stop_signal);
+	  resume (currently_stepping (ecs), stop_signal);
 	  prepare_to_wait (ecs);
 	  return;
 	}
 
-      /* It's a SIGTRAP or a signal we're interested in.  Switch threads,
-         and fall into the rest of wait_for_inferior().  */
-
-      context_switch (ecs);
-
-      if (context_hook)
-	context_hook (pid_to_thread_id (ecs->ptid));
-
-      flush_cached_frames ();
+      /* It's a SIGTRAP or a signal we're interested in.  Fall into the
+         rest of wait_for_inferior().  */
     }
 
   if (SOFTWARE_SINGLE_STEP_P () && singlestep_breakpoints_inserted_p)


  parent reply	other threads:[~2004-03-04 22:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-03 15:59 Atsushi Nemoto
2004-03-19  0:09 ` Atsushi Nemoto
2004-03-19  0:09 ` Atsushi Nemoto
2004-03-04 14:58   ` Atsushi Nemoto
2004-03-04 22:28   ` Daniel Jacobowitz [this message]
2004-03-19  0:09     ` Atsushi Nemoto
2004-03-05  2:25       ` Atsushi Nemoto
2004-03-19  0:09       ` Atsushi Nemoto
2004-03-05 16:36         ` Atsushi Nemoto
2004-03-05 16:38         ` Daniel Jacobowitz
2004-03-06 12:42           ` Atsushi Nemoto
2004-03-19  0:09             ` Daniel Jacobowitz
2004-03-06 17:11               ` Daniel Jacobowitz
2004-03-07 14:14               ` Atsushi Nemoto
2004-03-19  0:09                 ` Atsushi Nemoto
2004-03-19  0:09             ` Atsushi Nemoto
2004-03-19  0:09           ` Daniel Jacobowitz
2004-03-19  0:09     ` Atsushi Nemoto
2004-03-05  4:15       ` Atsushi Nemoto
2004-03-19  0:09     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040304222800.GA29911@nevyn.them.org \
    --to=drow@false.org \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox