From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5100 invoked by alias); 22 Jun 2002 06:00: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 5080 invoked from network); 22 Jun 2002 06:00:40 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Jun 2002 06:00:40 -0000 Received: from 01-058.118.popsite.net ([66.19.120.58] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17Ldwp-00022D-00; Sat, 22 Jun 2002 01:00:35 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17Ldwu-0001vS-00; Sat, 22 Jun 2002 02:00:40 -0400 Date: Fri, 21 Jun 2002 23:00: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: <20020622060040.GC7243@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> <20020621201847.GB23307@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/msg00198.txt.bz2 On Fri, Jun 21, 2002 at 05:37:27PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote: > > > 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? > > > > I should add to my previous comment that the use of libthread_db to > > access TLS data means that such will never be possible in a core file, > > either, without significant redesign of libthread_db - possibly as some > > sort of data file which can be loaded separately from the coredump and > > describe thread structures. > > Well, if the core file support is willing to reach into the notes and > construct a thread list, what's wrong with having it override the > `thread_local_storage_get_address' target method, too? Nothing, you're right. Whether the corefile will have the details to do this, however, without incorporating a large chunk of knowledge from various target libthread_db systems, though - that's dubious at best. At least there is an ABI to guide us. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer