From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26506 invoked by alias); 21 Jun 2002 21:55:36 -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 26388 invoked from network); 21 Jun 2002 21:55:33 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Jun 2002 21:55:33 -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 17LWNL-0001eq-00; Fri, 21 Jun 2002 16:55:28 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17LWNQ-00076h-00; Fri, 21 Jun 2002 17:55:32 -0400 Date: Fri, 21 Jun 2002 14:55:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage Message-ID: <20020621215532.GA27228@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , 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> <20020621201716.GA23307@nevyn.them.org> <20020621210302.GA25010@nevyn.them.org> <3D139E9D.70401@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D139E9D.70401@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00178.txt.bz2 On Fri, Jun 21, 2002 at 05:46:05PM -0400, Andrew Cagney wrote: > >This is the more substantial objection, it seems to me. But simply > >>because libthread_db can't be used for cross-platform core files > >>doesn't mean we shouldn't use it in the native case --- for the same > >>reasons we use it on live processes. > > > > > >Maybe.... I don't think the analogy holds. When we use it on live > >processes there is always a system (somewhere) on which thread_db could > >be running. That's why I was willing to use it in gdbserver. Of > >course, it's ONE MORE library that needs to be on all my targets now, > >which I'm not in love with. > > > >Debugging a core dump can't validly require access to a target. So > >making "native debug of a core dump" different from the hopeful "cross > >debug of a core dump" seems a bit dodgy. > > Yes. > > > I'd call the libthread_db > >approach broken for this purpose (a little outside its design scope > >perhaps). > > I think it reflects limitations of the current libthread-db interface > rather than a broken approach. I disagree... the concept of having a "libthread_db" with an interface involves it being a target library, part of the system. Unless you change its "interface" to be a data file rather than code, it requires access to a target in order to interpret target data. That's my whole objection to it. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer