From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13215 invoked by alias); 17 Dec 2001 01:02:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13008 invoked from network); 17 Dec 2001 01:00:43 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 17 Dec 2001 01:00:43 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16Fm93-0000ao-00; Sun, 16 Dec 2001 20:00:41 -0500 Date: Sun, 16 Dec 2001 17:02:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles Message-ID: <20011216200041.A935@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Snyder , gdb-patches@sources.redhat.com References: <20011213181006.A11536@nevyn.them.org> <3C193D13.AED0F79F@cygnus.com> <20011213185635.A12902@nevyn.them.org> <3C19543A.2580D12E@cygnus.com> <20011213232557.B20920@nevyn.them.org> <3C1AB5EE.1000506@cygnus.com> <20011214214103.A3900@nevyn.them.org> <3C1B854E.1000702@cygnus.com> <20011216152432.A4182@nevyn.them.org> <3C1D123E.3000900@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C1D123E.3000900@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00414.txt.bz2 On Sun, Dec 16, 2001 at 04:29:34PM -0500, Andrew Cagney wrote: > >Are we really comfortable with that? This'll probably cause GDB to > >misbehave in arbitrarily unpredictable ways in that circumstance. And > >we've no way to detect it that I can see. > > > By misbehave I guess you mean exibit non-deterministic behavour. Using > the current source base, either the GDB build is native and thread-db is > included (and full thread support in core files is available) XOR GDB is > a cross, thread-db is not included, and full thread support of core > files is not available. I think this is pretty deterministic. What do we really lose when you say "full thread support" is not available? For a thread == LWP model, everything except possibly internal LWP numbering is there, as far as I can tell. But that's beside the point. > As far as I know, these limitations are exactly the same as for GDB and > shared libraries. It just so happens that, for shared libraries, things > are a little (lot) further down the road of getting the technical > problems fixed. Not really the same. Debugging shared libraries you need: - to describe the link map. This is a fixed, generally unchanging, and simple structure. - to provide the target libraries. Debugging threads, you need a libthread_db which can run on the host and describe the target. The way linuxthreads_db is built it'll never do that. What worries me is that we have no way to find whether /lib/libthread_db.so.1 is compatible with the threads in a core dump. In any case, I'll try to bring it up for a normal native case later tonight. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer