Re: Trouble with gdbserver from gdb-5.3, glibc-2.3.2 on ppc32

Daniel Jacobowitz
2003-09-09T21:30:07Z

On Tue, Sep 09, 2003 at 05:22:41PM -0400, Daniel Jacobowitz wrote:
> On Tue, Sep 09, 2003 at 04:31:54PM -0400, Peter Barada wrote:
> >
> > I'm trying to bring up gdbserver2 on an ppc32 embedded linux platform, and
>
> What's gdbserver2? I'll just quietly assume you mean gdbserver...
>
> > I'm running in to the following message. It doesn't alway appear, so
> > it has me pretty confused....
> >
> > sh-2.05b# cat /proc/version
> > Linux version 2.4.21-rc1 (pbarada@hyper) (gcc version 3.3.1) #21 Tue Sep 9 15:43
> > sh-2.05b# gdbserver2 :3001 /usr/local/bin/page.strip -m16m -J < /dev/lp0
> > Process /usr/local/bin/page.strip created; pid = 35
> > Remote debugging from host 10.1.1.2
> > gdb: error initializing thread_db library.
> >
> > I modified gdbserver/thread-db.c::thread_db_init to print the value of
> > the err that is returned form td_ta_new, and the result is 0x16 which
> > if I read glibc-2.3.2/linuxthreads_db/thread_db.h correctly, the 0x16
> > returned from td_ta_new() is TD_VERSION which means the version of
> > libpthread doesn't match the version of libthread_db.
> >
> > If I look in gdb for the type of TD_VERSION I don't see TD_VERSION
> > even thos I see it in linuxthreads_db/thread_db.h:
> >
> > (gdb) ptype TD_OK
> > type = enum {TD_OK, TD_ERR, TD_NOTHR, TD_NOSV, TD_NOLWP, TD_BADPH, TD_BADTH, TD_BADSH,
> > TD_BADTA, TD_BADKEY, TD_NOMSG, TD_NOFPREGS, TD_NOLIBTHREAD, TD_NOEVENT,
> > TD_NOCAPAB, TD_DBERR, TD_NOAPLIC, TD_NOTSD, TD_MALLOC, TD_PARTIALREG, TD_NOXREGS}
> > (gdb) ptype TD_VERSION
> > No symbol "TD_VERSION" in current context.
> >
> > My question is how I can tell why gdbserver believes that the verion
> > of libpthread.so.0 doesn't match the version of libthread_db.so.1?
> > Whath options to readelf do I need?
> >
> > execution doesn't work after this (i.e. 'inf thr' doesn't show me my
> > thread, etc). I'm wondering if there's a deeper problem...
>
> Read the source of libthread_db? No, really. Then start another
> gdbserver debugging gdbserver, and step through td_ta_new. It fetches
> the version. This could be a symptom of symbol lookup being messed up,
> that's almost always the problem. Versions of the library on host and
> target match? GDB found the rght target libraries?

Amusingly, after writing that message, I just got:
warning: Cannot initialize thread debugging library: unknown thread_db error '22'

on my native setup. This happens when debugging a particular
statically linked executable that was built against a different version
of linuxthreads than is present on my host. Is that binary statically
linked?

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer