Re: Modification to support hybrid thread schedulers

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jul 16, 2009 at 01:55:03PM +0200, Kevin Pouget wrote:
> a little precision regarding this point, when you switch to a thread
> and ask for its backtrace, two situations may appear :
> 
> the thread is currently running on a LWP
> the thread is blocked in the scheduler
> 
> in the first case, GDB knows how to read the registers (via the
> proc-service interface), but in the second, they must be read in the
> memory (eg, in the jmp_buffer or in the mcontext_t)
> In the case of a kernel scheduler (NPTL), only the first option
> exists, and that is where the problems start. GDB/Linux short-cuts the
> Thread_db module, and read directly the registers on the LWP. It works
> correctly while the NPTL is used, but screws up the debugging of
> user/hybrid libraries ... GDB/Solaris doesn't have this behavior, as
> Solaris thread were hybrid until a recent time

Older versions of GDB supported the full range of libthread_db
operations on Linux.  But there were too many problems with
libthread_db, and bugs found in it, for us to continue.  The facts are
that linux-thread-db.c is specifically for GLIBC (and works well
enough for uClibc, most of the time).  It's just got an inappropriate
name.

One problem was that GLIBC was rarely updated for new registers
made available by the kernel.

You can find the patches in the list archives or CVS history that
removed the operations you're adding.  That may be helpful.

-- 
Daniel Jacobowitz
CodeSourcery