libthread_db.so question
Daniel Jacobowitz
drow@mvista.com
Tue Jul 15 19:31:00 GMT 2003
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
More information about the Gdb
mailing list