Re: RFC: A mode in which gdb avoids libthread_db

[Kevin Buettner <kevinb at redhat dot com>]

On Jul 26, 11:58am, Daniel Jacobowitz wrote:

> 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?

As a settable mode, this definitely sounds worthwhile.

Kevin