From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19185 invoked by alias); 21 Jun 2002 20:18:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18815 invoked from network); 21 Jun 2002 20:17:22 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Jun 2002 20:17:22 -0000 Received: from 01-056.118.popsite.net ([66.19.120.56] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17LUqI-0001Wg-00; Fri, 21 Jun 2002 15:17:15 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17LUqL-00066b-00; Fri, 21 Jun 2002 16:17:17 -0400 Date: Fri, 21 Jun 2002 13:18:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage Message-ID: <20020621201716.GA23307@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , gdb@sources.redhat.com References: <20020619160004.38A625EA11@zwingli.cygnus.com> <3D1282DD.7000508@cygnus.com> <20020621014821.GA7608@nevyn.them.org> <3D135FE5.6090605@cygnus.com> <20020621173249.GA11443@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00173.txt.bz2 On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Fri, Jun 21, 2002 at 01:18:29PM -0400, Andrew Cagney wrote: > > > >>BTW, what happens if the target doesn't have execution (i.e. a corefile). > > > > > > > >We fall down, just like we do debugging thread_db capable corefiles, > > > >I'd imagine. Thread_db does not like read-only targets very much. > > > > > > GDB on a threaded GNU/Linux target, again falls down, sigh! We can > > > hopefully have it working on other platforms. > > > > I beg your pardon? This is a thread_db limitation, not a GNU/Linux > > limitation. GNU/Linux copied the interface from Solaris and I believe > > we use it on Solaris. The effect there will be even more extreme than > > on GNU/Linux. Yes, we do use it on Solaris. > > > > If threaded corefiles work on Solaris I doubt it's by merit of > > thread_db. > > We can debug multi-threaded core files on Linux; see below. I must be > missing the point. But this works because the core file reader > actually goes and constructs the thread list itself. We're not using > thread_db to handle that. Which is sort of a bug --- what you see > when you run GDB on such a core file are LWP's, not threads. Yes. Search the archives to see the patch I committed to make this "bug" happen instead of trying to use libthread_db; that message also describes the problems. And if you're feeling ambitious, search for the message which describes why it broke libthread_db support for static executables. I haven't thought of a solution yet. > Why aren't we using thread_db, though? Why can't we run thread_db and > simply serve its memory and register requests from the core file? I > don't see which part of the interface makes this impossible. And > we'll need to do it if Linux switches to an NxM thread model, no? It's not interface but implementation. There's all sorts of places where libthread_db wants to write to the inferior. If you fake memory writes, it is possible that this would work; I couldn't figure out how to do that non-intrusively. Of much more interest to me is the fact that the LWP view of core files can be supported cross-platform and the thread_db view of core files can not be. That is IMO a very substantial design flaw in libthread_db. Not a problem if all the world's a SPARC, but after the effort I and others went through in order to make cross core debugging functional I'm reluctant to use libthread_db anywhere I can avoid it. An M:N implementation of libthread_db is even more likely to want to write to or signal the inferior process. I don't know if Sun's handles this gracefully or if they grub through the corefile looking for threads like we do. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer