* Re: [Fwd: [Fwd: Caught signal 9 in core file ????]] [not found] <m3adxww98v.fsf@north-pole.nickc.cambridge.redhat.com> @ 2001-11-08 14:53 ` Peter.Schauer 2001-11-24 10:06 ` Nick Clifton 0 siblings, 1 reply; 3+ messages in thread From: Peter.Schauer @ 2001-11-08 14:53 UTC (permalink / raw) To: Nick Clifton; +Cc: ac131313, binutils, gdb, Chabane.Rezzik, gnu-gdb-bug > 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Fwd: [Fwd: Caught signal 9 in core file ????]] 2001-11-08 14:53 ` [Fwd: [Fwd: Caught signal 9 in core file ????]] Peter.Schauer @ 2001-11-24 10:06 ` Nick Clifton 2001-11-29 2:34 ` Nick Clifton 0 siblings, 1 reply; 3+ messages in thread From: Nick Clifton @ 2001-11-24 10:06 UTC (permalink / raw) To: Peter.Schauer; +Cc: ac131313, binutils, gdb, Chabane.Rezzik, gnu-gdb-bug 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Fwd: [Fwd: Caught signal 9 in core file ????]] 2001-11-24 10:06 ` Nick Clifton @ 2001-11-29 2:34 ` Nick Clifton 0 siblings, 0 replies; 3+ messages in thread From: Nick Clifton @ 2001-11-29 2:34 UTC (permalink / raw) To: Peter.Schauer; +Cc: ac131313, binutils, gdb, Chabane.Rezzik, gnu-gdb-bug 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-11-29 10:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <m3adxww98v.fsf@north-pole.nickc.cambridge.redhat.com>
2001-11-08 14:53 ` [Fwd: [Fwd: Caught signal 9 in core file ????]] Peter.Schauer
2001-11-24 10:06 ` Nick Clifton
2001-11-29 2:34 ` Nick Clifton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox