This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: John Utz <Johnut01 at noa dot nintendo dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 23 Jan 2004 17:50:24 -0500
- Subject: Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?
- References: <s0112c91.027@smtpgw1.nintendo.com>
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