RFC: A mode in which gdb avoids libthread_db

[Daniel Jacobowitz <drow at mvista dot com>]

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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer