gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[Daniel Jacobowitz]

On Fri, Jan 23, 2004 at 02:15:28PM -0800, John Utz wrote:
> > 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! )????

Sorry, I misspoke, it doesn't matter what libthread_db the client uses. 
My concern was actually that it loads the correct libpthread.so.

If it's still segfaulting you've found a new or unique problem.  You'll
have to figure out what gdbserver is doing :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer