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
- From: Atsushi Nemoto <anemo at mba dot ocn dot ne dot jp>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 05 Mar 2004 00:05:40 +0900 (JST)
- Subject: Re: remote debugging a multi-threaded program with signal
- References: <20040304.010624.59462252.anemo@mba.ocn.ne.jp>
>>>>> 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?
---
Atsushi Nemoto