Re: gdb/threading under arm-linux

[Daniel Jacobowitz <drow@mvista.com>]

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