From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28984 invoked by alias); 19 Nov 2001 21:41:53 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28861 invoked from network); 19 Nov 2001 21:41:49 -0000 Received: from unknown (HELO rennsau.regent.e-technik.tu-muenchen.de) (129.187.231.63) by sourceware.cygnus.com with SMTP; 19 Nov 2001 21:41:49 -0000 Received: from reisser.regent.e-technik.tu-muenchen.de (reisser.regent.e-technik.tu-muenchen.de [129.187.231.143]) by rennsau.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) with ESMTP id WAA22294 ; Mon, 19 Nov 2001 22:41:37 +0100 (MET) From: "Peter.Schauer" Received: (pes@localhost) by reisser.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) id WAA14933 ; Mon, 19 Nov 2001 22:41:37 +0100 (MET) Message-Id: <200111192141.WAA14933@reisser.regent.e-technik.tu-muenchen.de> Subject: Re: [Fwd: [Fwd: Caught signal 9 in core file ????]] To: nickc@cambridge.redhat.com (Nick Clifton) Date: Thu, 08 Nov 2001 14:53:00 -0000 Cc: ac131313@cygnus.com, binutils@sources.redhat.com, gdb@sources.redhat.com, Chabane.Rezzik@usa.alcatel.com, gnu-gdb-bug@gnu.org In-Reply-To: ; from "Nick Clifton" at Nov 9, 101 11:43 am X-Mailer: ELM [version 2.3 PL6] X-SW-Source: 2001-11/txt/msg00094.txt.bz2 > 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. > Hi Andrew, > > > Something that has been kicking around the GDB list but is really a > > BFD problem. Anyone want to grab this and run with it? I don't > > know enough about core dumps to do the job myself. > > Sadly neither do I. The patch however looks wrong to me. With the > patch applied, the code looks like this: > > > offset = offsetof (prstatus_t, pr_reg); > > memcpy (&prstat, note->descdata, sizeof (prstat)); > > > > ! if (elf_tdata (abfd)->core_signal == 0) > > ! elf_tdata (abfd)->core_signal = prstat.pr_cursig; > > elf_tdata (abfd)->core_pid = prstat.pr_pid; > > > > /* pr_who exists on: > > So it seem that if core_signal has already been set (from a previous > thread ?) then it will not be overwritten. But the process ID will be > changed, so now you have a signal and a PID that do not match... > > 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 ? > > Cheers > Nick -- Peter Schauer pes@regent.e-technik.tu-muenchen.de