From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8402 invoked by alias); 23 Jan 2004 22:15:48 -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 8395 invoked from network); 23 Jan 2004 22:15:46 -0000 Received: from unknown (HELO smtpgw1.nintendo.com) (205.166.76.16) by sources.redhat.com with SMTP; 23 Jan 2004 22:15:46 -0000 Received: from Gateways-MTA by smtpgw1.nintendo.com with Novell_GroupWise; Fri, 23 Jan 2004 14:15:45 -0800 Message-Id: Date: Fri, 23 Jan 2004 22:15:00 -0000 From: "John Utz" To: Cc: Subject: Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2004-01/txt/msg00278.txt.bz2 Further information: >>> Daniel Jacobowitz 01/23/04 12:34PM >>> > On Fri, Jan 23, 2004 at 12:32:18PM -0800, John Utz wrote: > > problem i am having is that when gdbserver tries to load the symbols > for for libpthread-0.9.so, it segfaults. > > 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. > > Google for solib-absolute-prefix. went to the manual. :-) here's my updated .gdbinit [johnut01@gbcxdev johnut01]$ more .gdbinit define rstpc set solib-absolute-prefix /home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/ set solib-search-path /home/johnut01/GBCX/allegro4.0.3/:/home/johnut01/GBCX/gbc x-cvs-tree/gbcxlinux/mas-seatapi file /home/johnut01/GBCX/noa/gbcxLinux target remote dseb:2345 break main continue #share #break dlopen #c end > Strace gdb if necessary to see what it finds. that was interesting, and supports your argument, note that it's loading the host thread_db, and the correct target libpthread.so.0 [johnut01@gbcxdev johnut01]$ grep thread stracegdb.txt open("/lib/tls/libthread_db.so.1", O_RDONLY) = 3 open("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0", O_RDONLY) = 8 stat64("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0", {st_mode=S_IFREG|0755, st_size=464868, ...}) = 0 open("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0", O_RDONLY) = 11 it doesnt appear to me that solib-absolute-prefix has anything to do with what libthread_db gdb loads, and from what little i understand about sharedlibs under linux, it's not *supposed* to. as i understand it the solib* variables manage the 'internal universe' of gdb and by implication, gdbserver. but which sharedlibs the linker chooses to use to resolve gbd's needs from the 'external universe' isnt manageable from inside of gdb...this looks like a job for LD_LIBRARY_PATH ( boo, hiss! )???? feel free to humilate me publicly if i have this wrong and there is a solution other than the one i propose..... :-) tnx! johnu -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer