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: Thu, 04 Mar 2004 22:28:00 -0000 [thread overview]
Message-ID: <20040304222800.GA29911@nevyn.them.org> (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)
WARNING: multiple messages have this Message-ID
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)
next prev 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-04 14:58 ` Atsushi Nemoto
2004-03-04 22:28 ` Daniel Jacobowitz [this message]
2004-03-19 0:09 ` Daniel Jacobowitz
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 ` Atsushi Nemoto
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