Re: gdbserver coredumps,what is the *right* libthread_db.sofor gdbserver on a given platform?

["John Utz" <Johnut01 at noa dot nintendo dot com>]

Further information:

>>> Daniel Jacobowitz <drow@mvista.com> 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