This is the mail archive of the
mailing list for the GDB project.
Re: [Fwd: [Fwd: Caught signal 9 in core file ????]]
- From: Nick Clifton <nickc at cambridge dot redhat dot com>
- To: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Cc: ac131313 at cygnus dot com, binutils at sources dot redhat dot com,gdb at sources dot redhat dot com, Chabane dot Rezzik at usa dot alcatel dot com,gnu-gdb-bug at gnu dot org
- Date: 29 Nov 2001 10:32:17 +0000
- Subject: Re: [Fwd: [Fwd: Caught signal 9 in core file ????]]
- References: <200111192141.WAA14933@reisser.regent.e-technik.tu-muenchen.de>
> > I can see why you would want to preserve the signal, but shouldn't you
> > also preserve the PID (and any other core related data) as well ? In
> > fact isn't this really a multithreading problem, with a single BFD
> > structure being used to represent multiple (potential) thread cores ?
> It wouldn't matter for Solaris (and as I said, using the first note section
> for the signal in the currently running thread is a Solaris convention, which
> might not be true on other platforms), as prstat.pr_pid is the same for all
> Using per thread signal/pid descriptions would gain nothing on Solaris, as
> the pid is all the same and the signal in all not currently running threads
> is SIGKILL. I suspect that something similar will happen on other platforms
> as well though.
Fair enough, in which case I will apply the patch. I realise that
this is not a full solution, but if it helps to get the ball rolling,
then that is a good thing.