> "SethMeister G." <consp05@binghamton.edu> writes:
> >
> > Is this really necessary? I mean, if you are using a thread library that
> > gdb knows how to handle, why can't it glean the important information
> > from the core image as is (but I am ASSuME ing a lot of stuff that I
> > don't know).
> >
> Gdb does _not_ know how to handle Linux kernel threads.
>
> The core image as it is contains only CPU state for the one thread which
> caused the fault. All the other threads continue running. This may or may
> be what you want... right now, unfortunately, you can't control this.
I'm also assuming a great deal, so I'm asking questions, primarily. ;)
A program screws up and manages to generate, say, a SIGILL. It goes to the
signal handler. The program hasn't trapped it, so it passes to the libc
default handler. That default handler generates a coredump and blows the
process away.
The only thing that will die, though, is the thread that receieved the
signal (mainly because with linuxthreads we're using clone() as a fork()
variant to spawn child processes?). The other threads go on, happy as
proverbial clams.
Now someone could throw on a wrapper that informs all the other threads,
probably by using some common data area and a general signal, that their
sister died. They could then handle what they wanted. However, if *they*
generated core dumps, they'd overwrite what was there.
How hard would it be to update gdb to handle linuxthreads, and everything
else to support some kind of total core dump for debugging? Would we ever
even want to do this? I'm assuming a major hack of gdb, and a (minor?)
hack of glibc.
I wonder how many of my above assumptions are incorrect. ;)
-- Good government. Good government. Sit. Stay.