This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [Fwd: [Fwd: Caught signal 9 in core file ????]]
- From: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- To: nickc at cambridge dot redhat dot com (Nick Clifton)
- 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: Mon, 19 Nov 2001 22:41:36 MET
- Subject: Re: [Fwd: [Fwd: Caught signal 9 in core file ????]]
> 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