This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdbserver, pthreads and SIGPWR
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: "Kremer Markus (PN-SYS/TSF)" <Markus dot Kremer at Tenovis dot com>,gdb at sources dot redhat dot com
- Date: Thu, 7 Mar 2002 13:08:33 -0500
- Subject: Re: gdbserver, pthreads and SIGPWR
- References: <D88EDE4925921A4A8C22C3968371C4671C400A@defrm011.tenovis.corp.lan> <3C87A960.2010207@cygnus.com>
On Thu, Mar 07, 2002 at 12:54:40PM -0500, Andrew Cagney wrote:
> >Hello,
> >i am using gdb 5.1.1 to remote debug my programs.
> >whenever i create a new thread with pthread_create(), a SIGPWR is caught.
> >
> >Why does this happen when i do remote debugging, but not, when i use gdb
> >directly?
> >What should i do when the signal arrives?
> >Can i continue savely?
>
> (I'm guessing a remote GNU/Linux target).
>
> Try:
> (gdb) help handle
> (gdb) handle SIGPWR pass nostop noprint
> I suspect the SIGPWR is being used as part of the thread implementation.
> You're probably also going to find that threads don't work very well
> remotely, I don't know of many debug agent implementations that support
> threads.
SIGPWR is some random low-numbered signal.
TARGET_SIGNAL_SIGPWR is 32.
This is actually SIG32, the thread management signal.
And what Andrew said about debugging threads remotely is true, at least
for now. It will not work well.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer