From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5431 invoked by alias); 23 Jan 2004 20:48:55 -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 5424 invoked from network); 23 Jan 2004 20:48:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 23 Jan 2004 20:48:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Ak8EY-0001TY-JK; Fri, 23 Jan 2004 15:48:54 -0500 Date: Fri, 23 Jan 2004 20:48:00 -0000 From: Daniel Jacobowitz To: John Utz Cc: gdb@sources.redhat.com Subject: Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform? Message-ID: <20040123204854.GA5648@nevyn.them.org> Mail-Followup-To: John Utz , gdb@sources.redhat.com References: 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: 2004-01/txt/msg00275.txt.bz2 On Fri, Jan 23, 2004 at 12:42:25PM -0800, John Utz wrote: > Hi Daniel! > > tnx so much for responding. > > >>>> Daniel Jacobowitz 01/23/04 12:34PM >>> > >On Fri, Jan 23, 2004 at 12:32:18PM -0800, John Utz wrote: > >> Hi; > >> problem i am having is that when gdbserver tries to load the > symbols > >> for for libpthread-0.9.so, it segfaults. > >> > >> it seems to not matter *which* libthread_db.so i stuff into my > search > >> path on the target > > > > It doesn't matter what's on your search path on the _TARGET_. The > > segfault is usually a symptom that the libthread_db loaded on the > > _HOST_ does not match the one in use on the target system. > > remarkably interesting! what does gdbserver us thread_db for? i noticed > that when i puposefully deleted -lthread_db it actually only uses a few > calls from libthread_db....if you could enlighten me about that i would > be really grateful. It uses it for those calls, of course. Specifically, to locate new threads after pthread_create. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer