This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Multiple threads in one corefile on Linux--gdb support?
- To: Eric Paire <paire at ri dot silicomp dot fr>
- Subject: Re: Multiple threads in one corefile on Linux--gdb support?
- From: "George T. Talbot" <george at moberg dot com>
- Date: Wed, 10 May 2000 09:23:22 -0400
- CC: gdb at sourceware dot cygnus dot com
- Organization: Moberg Research, Inc.
- References: <200005100639.IAA23303@mailhost.ri.silicomp.fr>
Eric Paire wrote:
>
> > I've done a kernel patch for Linux which dumps multiple threads into different
> > corefiles named core.##### where ##### is the PID. I've been told that the
> > ELF format'll support multiple register in a core file by having >1 PT_NOTE
> > section.
> >
> > If I patch the kernel to dump the multiple register sets into a single core,
> > will GDB with LinuxThreads support recognize the corefile without
> > modification?
> >
> Two years ago, when I first developed the gdb extension for debugging
> LinuxThreads applications, Philip Gladstone <philip@raptor.com> sent to me
> patches for gdb-4.16 and Linux kernel in order to generate multithreaded
> core dumps within the regular ELF format (exactly as you suggest).
>
> Linus Torvalds has never included these patches into the kernel since they
> require that the kernel kills all clones of the thread doing the core dump,
> probably because it forces a given semantic to the cloned processes inside
> the kernel.
Why kill all the cloned processes? Just pause them during the core dump...
In any case, do you guys save what Linus said? I.E. his actual objections?
> Last year, I have suggested another philosophy for LinuxThread core dumps
> which does not require any kernel modification, and which I have never had
> enough spare time to implement. Everything is done in gdb and in the
> LinuxThread library. Here is a rough description of it:
>
> 1) attach a signal handler to all signals (except SIGKILL and SIGSTOP
> obviously) which will be called with the sigcontext,
> 2) on signal (generating a core dump) reception, signal all other threads,
> 3) on each thread receiving the signal, store the context in a reserved
> thread-private part (usually into their own stack),
> 4) wait for the end of all threads but one (the manager one ?)
> 5) when only one thread remain, reset signal handler to default and resend
> original signal to itself, which may or may not generate a core dump,
> depending on the kernel implementation.
>
> The kernel generates then a standard unithreaded core dump, which contains
> the current status of all threads.
> 6) gdb then retreives the status of all threads by retreiving internally the
> status of all threads at the place it has been stored since the
> memory is shared between all threads, including their private stack.
>
> This schema has two advantages:
> 1) it does not require any kernel modification (which should please Linus
> Torvalds ;-)
> 2) it is completely core format and processor-independent (ELF format does not
> cover all processors).
>
> The usual comment I have received is that the status of all threads will not
> be the one at the time the original one received the signal, since thread
> signaling is done in user mode and other threads may have run. This is true
> for uniprocessor machines, but it is almost impossible to have the exact
> status of all others threads at the time the thread died on a multiprocessor,
> since other threads may run on different processors and during the time
> signal is handled, the other threads may have run several instructions before
> being stopped (which is a general problem of debugging MT applications).
>
> -Eric
> P.S. nevertheless, I have kept the original patches of Philip Gladstone which
> I can resend to interested people.
Would it be possible to do as you suggest in user-space, and also write the
core file with multiple register sections from user space so as to be
compatible with debuggers ported from other platforms?
Just thinking out loud...
--
George T. Talbot
<george at moberg dot com>