This is the mail archive of the gdb@sources.redhat.com 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: libthread_db.so question


On Tue, Jul 15, 2003 at 12:29:14PM -0700, Pete Huerter wrote:
> Hi,
> 
> Is it possible to use the libthread_db.so library functions to debug a
> remote process and it's threads?  I.e. must the client of
> libthread_db.so be running on the same host as the target process
> itself?
> 
> The debugger I work on currently controls remote processes via a
> ptrace-based remote debug server.   It seems that with the coming of
> RedHat 9.0 the old linuxthreads interface that we are currently using is
> deprecated, forcing us to move to using libthread_db.so instead.  The
> debugger can debug a distributed (MPI-based) multi-threaded
> (linuxthread-based OpenMP) program.  It uses a remote debug server to
> control and inspect each remote node.  Must libthread_db.so be loaded by
> each remote debug server?  or can the debugger load a single
> libthread_db.so and use it's facilities to control the remote processes
> (if a proc_service interface is implemented to them using the low level
> (remote) ptrace-based interface of the remote debug server).
> 
> >From reading the man pages on libthread_db.so:
> 
> "libthread_db relies on an "agent thread" in the target process for some
> of its operations. The "agent thread" is a system thread started when
> libthread_db attaches to a process through td_ta_new(3T) ."
> 
> Is an agent thread created for each target process?  Is the agent thread
> a child thread of each target process?
> 
> I realize this is a specialized question.  If there is a better place to
> direct this question, please let me know.

I imagine you could load libthread_db on the host.  However, it's
slower, and it requires that the host be running the same glibc version
as the target.  That's why gdbserver loads libthread_db on the target
instead.

The ps_* facilities required by libthread_db are quite minimal.  The
only heavy one is symbol lookup; we use a callback to the client for
that.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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