From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13576 invoked by alias); 16 Jul 2009 12:03:59 -0000 Received: (qmail 13566 invoked by uid 22791); 16 Jul 2009 12:03:58 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Jul 2009 12:03:50 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CF854109FF; Thu, 16 Jul 2009 12:03:48 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id A9165108A5; Thu, 16 Jul 2009 12:03:48 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MRPgh-0002sc-GS; Thu, 16 Jul 2009 08:03:47 -0400 Date: Thu, 16 Jul 2009 12:03:00 -0000 From: Daniel Jacobowitz To: Kevin Pouget Cc: gdb@sources.redhat.com Subject: Re: Modification to support hybrid thread schedulers Message-ID: <20090716120347.GA10752@caradoc.them.org> Mail-Followup-To: Kevin Pouget , gdb@sources.redhat.com References: <57e4a4fe0907160452t28770d13n50c19c8ebe5e034c@mail.gmail.com> <57e4a4fe0907160455q3ec0b66fl722f5f85a48d6dab@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57e4a4fe0907160455q3ec0b66fl722f5f85a48d6dab@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00101.txt.bz2 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