Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* 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