From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9930 invoked by alias); 21 Jun 2002 21:03:15 -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 9840 invoked from network); 21 Jun 2002 21:03:04 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Jun 2002 21:03:04 -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 17LVYZ-0001af-00; Fri, 21 Jun 2002 16:02:59 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17LVYe-0006Yr-00; Fri, 21 Jun 2002 17:03:04 -0400 Date: Fri, 21 Jun 2002 14:03: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: <20020621210302.GA25010@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> <20020621201716.GA23307@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/msg00176.txt.bz2 On Fri, Jun 21, 2002 at 03:54:12PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > 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. > > Great, thanks. > > > 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. > > I'm not that ambitious 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. > > All the calls to ps_p[td]write I see in GNU's libthread_db have to do > with the implementation of events. Can't we just ignore those writes? > Or better yet, make gdb/thread-db.c smart enough not to set event > breakpoints in the first place when the underyling target doesn't have > execution? I tried that; there was some other problem. It might have been in my implementation. Indeed upon looking back at it I see that you are correct. Maybe it would work. > > 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. > > 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. I'd call the libthread_db approach broken for this purpose (a little outside its design scope perhaps). -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer