From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21815 invoked by alias); 2 Mar 2003 18:33:00 -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 21808 invoked from network); 2 Mar 2003 18:33:00 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 2 Mar 2003 18:33:00 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18pa9y-0005gl-00; Sun, 02 Mar 2003 14:34:10 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18pYGf-0005Y1-00; Sun, 02 Mar 2003 13:32:57 -0500 Date: Sun, 02 Mar 2003 18:33:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: expected behavior of GNU/Linux gcore and corefiles Message-ID: <20030302183257.GA21281@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <3E617797.5000704@redhat.com> <20030302033900.GA14335@nevyn.them.org> <20030302034653.GA14491@nevyn.them.org> <3E622998.5020104@redhat.com> <20030302170911.GA20234@nevyn.them.org> <3E624DEC.7040108@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E624DEC.7040108@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00031.txt.bz2 On Sun, Mar 02, 2003 at 01:31:08PM -0500, Andrew Cagney wrote: > >On Sun, Mar 02, 2003 at 10:56:08AM -0500, Andrew Cagney wrote: > > > >>>On Sat, Mar 01, 2003 at 10:39:00PM -0500, Daniel Jacobowitz wrote: > >>> > > > >>>>> My instincts tell me that, to completly implement the above > >>>>> functionality, GDB is always going to need libthread-db. If GDB > >>could >>> implement the above on a core file without using libthread-db, > >>then GDB >>> could also implement the above on a live target also without > >>using >>> libthread-db. This is because a core file is always going to > >>contain a >>> subset of the information made available via ptrace et.al. > > > >>> > >>> > >>>Oh, and one other thing that I like to mention when this comes up. My > >>>previous message was the implementation issues involved; this one's the > >>>motivational issue. Thread_db is not, and can't/shouldn't be, > >>>available in a cross environment. We have done a lot of work to make > >>>GDB read corefiles in a cross environment; and at MontaVista we've seen > >>>a large demand for this functionality from our customers. So using > >>>thread_db with corefiles doesn't meet our (GDB developers') goals, I > >>>think. > > > >> > >>Sorry, on this point, I'm lost. What are you suggesting here? > > > > > >My point is just that it's important for GDB to not require thread_db > >when dealing with core files. A lot of people seem to use e.g. Solaris > >to debug core files and expect everything they would get from using GDB > >natively; that's their expectation and so far we've been able to stay > >pretty much there. > > If that position means precluding certain native-only functionality? Not exactly; if that native-only functionality precludes keeping what we have now for non-thread_db setups and extending it. For instance, I think we should always be able to print LWP state (assuming a 1-1 mapping when we have no thread_db to ask for more information). And I think we should add support for TLS based only on LWPs, since it's not dependent on the thread manager. If we can't "info mutex" on a cross corefile, well, that's the same as now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer