From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Clifton To: "Peter.Schauer" Cc: ac131313@cygnus.com, binutils@sources.redhat.com, gdb@sources.redhat.com, Chabane.Rezzik@usa.alcatel.com, gnu-gdb-bug@gnu.org Subject: Re: [Fwd: [Fwd: Caught signal 9 in core file ????]] Date: Thu, 29 Nov 2001 02:34:00 -0000 Message-ID: References: <200111192141.WAA14933@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2001-11/msg00335.html Message-ID: <20011129023400.gBOCNIgmoR_1vub-hPK2C5LoKvwmGE4n3RoAHp6Ydxc@z> Hi Peter, > > 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 > threads. > 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. Cheers Nick