This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: howto debug libthread_db


On Wed, 2006-09-27 at 08:23 +0200, Carmelo Amoroso wrote:
> Michael Snyder wrote:
> > On Tue, 2006-09-26 at 16:06 +0200, Carmelo Amoroso wrote:
> >> Hi All,
> >> I'm trying to debug a simple multithread application on a remote target,
> >> and I like to debug the libthread_db itself... is it possible to do it? 
> >> is it possible to set some breakpoints and stepping through?
> >> Is there anyone already played with it?
> >>
> >> I tried to use symbol-file to gdb client, and I successfully added a 
> >> breakpoint, but I cannot reach it after I connected to the target and 
> >> issued 'continue'.
> >>
> >> Any help will be appreciated
> > 
> > Interesting.  I haven't done it (or not much anyway).
> > 
> > The first thing you must bear in mind is that libthread_db is not
> > part of the target application -- it is part of gdb (or in the
> > remote debugging context, part of gdbserver).  So to debug it, 
> > you must debug gdb, or in your case gdbserver.
> > 
> Yes. it's what I want to do

> > It might be easier if you try this out first using a native gdb, 
> > debugging itself.  
> > 
> > When you debug gdb with gdb, it is easier if you change the prompt.
> > I usually do this in the 'parent' gdb, so I can tell it apart from
> > the 'child' gdb:
> > 
> > 	(gdb) set prompt (GDB) 
> > 	(GDB) 
> > 
> > Now, in the parent GDB, you should be able to set your 
> > breakpoints in libthread_db, then start the child gdb, 
> > load the multi-threaded program, and begin debugging it.
> > 
> Does the native gdb use the thread_db as the gdbserver does?

Yes.

> I was thinking to run gdb --args my-gdbserver <application>
> on the target, and connect to the my-gdbserver from the host
> just to trigger the thread_db initialization process.
> Comments?

Oh, so you can actually run gdb on the target?
Yes, that would make things simpler, and what you
suggest above is pretty much what I would recommend.


> > When you get ready to try this with gdbserver, you will
> > have to start one gdbserver and attach to it with another
> > gdbserver.  Then you'll again have two gdbs running on the
> > host side, which you can again think of as parent and child, 
> > only now the parent is debugging the child's gdbserver, not
> > the child gdb itself.
> > 
> 
> Well, just before reading your reply, I tried with this:
> 
> target:
> gdbserver localhost:999 my-gdbserver localhost:998 <applcation>
> 
> host:
> xxx-gdb my-gdbserver (connecting to port 999)
> 
> xxx-gdb application (connecting to port 998)
> 
> With the first gdb session I was able to set a breakpoint into
> thread_db, but not able to stepping through the code.
> 
> Is this approach as well as the gdb native session.

Hmmm, that's pretty much what I would have tried.
What happened when you tried to step?  How did it fail?





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]