From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30095 invoked by alias); 26 May 2002 02:32:46 -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 30086 invoked from network); 26 May 2002 02:32:45 -0000 Received: from unknown (HELO branoic.WV.CC.CMU.EDU) (128.2.71.182) by sources.redhat.com with SMTP; 26 May 2002 02:32:45 -0000 Received: from drow by branoic.WV.CC.CMU.EDU with local (Exim 3.35 #1 (Debian)) id 17Bnpq-0002G9-00; Sat, 25 May 2002 22:32:42 -0400 Date: Sat, 25 May 2002 23:13:00 -0000 From: Daniel Jacobowitz To: Marius Groeger Cc: gdb-patches@sources.redhat.com, Daniel Junglas , Wolfgang Denk Subject: Re: Multi-Threaded Extensions for GdbServer Message-ID: <20020526023242.GA8626@branoic.them.org> Mail-Followup-To: Marius Groeger , gdb-patches@sources.redhat.com, Daniel Junglas , Wolfgang Denk References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2002-05/txt/msg00915.txt.bz2 On Wed, May 22, 2002 at 10:50:24AM +0200, Marius Groeger wrote: > Hi all, > > several people asked me to post this to the wider audience of gdb > developers. AFAIK there are several approaches for extending the > gdbserver to be able to debug remote programs that use threads. The > attached patch does this. The main advantage of it is that it doesn't > require libthread_db or symbol information on the target. We need > this for debugging of embedded targets with limited resources. > The main downside of the patch is that it's for some pretty ancient > 5.0 snapshot (20010427). It also contains a small number of general > fixes which are not related to MT debugging. Not needing symbol information on the target is definitely the way to go, but libthread_db is very small and has better reliabilty. I'm still finishing the legal legwork to get this work committed (I've already finished it); it should be early next week (really!). After that I'll take a better look at what you've sent; it may have useful advantages that I can merge into the existing code. It would be nice to support both with and without thread_db. I notice that you added glibc specific code to remote.c and some protocol extensions; that makes this unsuitable to just drop in. I believe you needed the same extension that was added in a later version of GDB for looking up symbols, so this isn't a big deal in any case. Thanks! -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer