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 ????]]
- To: ac131313 at cygnus dot com
- Subject: Re: [Fwd: [Fwd: Caught signal 9 in core file ????]]
- From: Nick Clifton <nickc at cambridge dot redhat dot com>
- Date: 09 Nov 2001 10:04:32 +0000
- Cc: Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de,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
- References: <3BEA0C18.9040500@cygnus.com>
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