From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1919 invoked by alias); 21 Jun 2002 20:54:16 -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 1873 invoked from network); 21 Jun 2002 20:54:15 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 21 Jun 2002 20:54:15 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 3D93E5EA11; Fri, 21 Jun 2002 15:54:13 -0500 (EST) To: Daniel Jacobowitz Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage 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> From: Jim Blandy Date: Fri, 21 Jun 2002 13:54:00 -0000 In-Reply-To: <20020621201716.GA23307@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-06/txt/msg00175.txt.bz2 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? > 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.