This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb/threading under arm-linux
On Wed, Mar 13, 2002 at 05:43:08PM +0000, Miah Gregory wrote:
> In message <20020313120947.A12715@nevyn.them.org>
> Daniel Jacobowitz <drow@mvista.com> wrote:
>
> > On Wed, Mar 13, 2002 at 01:11:57PM +0000, Miah Gregory wrote:
>
> > > In message <20020306110033.A14410@nevyn.them.org>
> > > Daniel Jacobowitz <dmj+@andrew.cmu.edu> wrote:
>
> > > > You almost certainly do not have libthread_db.so.1 in /lib.
> > > > You need that to debug threads.
>
> > > Ok, I managed to build enough of libc 2.2.3 in order to get the
> > > required libthread_db.so.1 library, and I then installed that in /lib.
>
> > > With the 20020305 snapshot, I get all the same problems. Is there a
> > > simple way to find out whether gdb is trying to use that library?
>
> > I recommend running gdb within gdb, and breakpointing on
> > thread_db_load.
>
> Sounds reasonable.
>
> When I do that, gdb makes its way through thread_db_init to the final
> 'return 1;', which I assume from the code means that it opened and
> initialised libthread_db correctly.
>
> Anything else I can break on? Which function is called when a new thread is
> created?
>
> Running gdb from start to finish, these are the only functions within
> thread_db.c that are called, in order:
>
> thread_db_load
> init_thread_db_ops
> thread_db_init
> thread_db_new_objfile (objfile = 0x0000000)
> thread_db_new_objfile (objfile = 0x2207e18)
Might want to step through thread_db_new_objfile. Is something causing
it to turn off thread_db?
Wait, from that pattern of calls it looks like you are using a
statically linked binary. Try using a dynamically linked binary, and
I'll take another look at HJ's patch to fix the static case :)
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer