Re: RFC: A mode in which gdb avoids libthread_db

[Elena Zannoni <ezannoni at redhat dot com>]

Daniel Jacobowitz writes:
 > Recent Linux kernels (2.5.30 and later; theoretically the latest Red Hat
 > 2.4.20 kernels also include it, but I observed some badness in testing...)
 > support some ptrace extensions I designed which make it possible to debug
 > multi-threaded applications without using libthread_db at all.  The only
 > things we'll lose are:
 >   - Potential high-level information, like mutex status - right now we
 >     don't have this at all on GNU/Linux.
 >   - TLS access - this could be easily fixed by handling each platform's
 >     TLS ABI directly from GDB, and there's a comment to that effect in
 >     GDB's source already.
 >   - TIDs - we'd only have the application's LWP IDs, not the thread IDs
 >     that LinuxThreads/NPTL use.
 > 
 > Things we'll gain:
 >   - A lot of libthread_db-related bugs would go away.  For instance,
 >     the kfail in print-threads.exp, which hits a breakpoint after
 >     LinuxThreads decides the thread has already exited.
 >   - ABI simplicity - this would solve the x86-64/i386 issue, and similar
 >     problems on MIPS.
 >   - Support for debugging clone-based 1-1 threading which doesn't use
 >     libpthread.so.
 > 
 > Once the pending fork-debugging patch is accepted, most of the machinery
 > we'd need to do it will be in place, too.  Thoughts?  Worthwhile?


I know first hand of the pains of mismatched glibcs, binutils,
kernels, gdbs.  I wouldn't mind having this coexist with the use of
glibc, is that possible?

What ptrace changes did you do? (Elena needs to start reading
linux-kernel)

elena


 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer