This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[RFC] Reference implementation for remote symbol lookup.
- To: gdb-patches at sources dot redhat dot com
- Subject: [RFC] Reference implementation for remote symbol lookup.
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Thu, 26 Apr 2001 14:44:44 -0700
- Organization: Red Hat
In an earlier message, I described a proposed remote protocol extension to allow
a remote target to request symbol look-up from the debugger. In a nutshell, the
extension allows the debugger to notify the target when a new symbol file such as
a shared library becomes available, whereupon the target may reply with one or more
requests for the value of a symbol.
I now have a reference implementation of a target that uses this functionality.
This target needs symbols from the pthreads target library, so that it can
use the "libthread_db" debugger interface to debug threads. Libthread_db uses
the addresses of data structures in the debuggee to discover how many threads
are active, etc.
The target basically accumulates a list of symbols that it needs
(because of requests from libthread_db). Whenever GDB sends notification
that a new shared library has been loaded, the target traverses the list
of unsatisfied symbols once. Thus the target makes use of state information:
a) which symbol values are still needed, and
b) which ones have been requested so far for this shared library.
A typical session looks like this:
Sending packet: $QSharedObject:/libpthread.so.0#f5...Ack
Packet received: qSymbol:__pthread_threads_events
Sending packet: $QSymbol:400336e8:__pthread_threads_events#ec...Ack
Packet received: qSymbol:__pthread_last_event
Sending packet: $QSymbol:400336f0:__pthread_last_event#3b...Ack
Packet received: qSymbol:__pthread_handles_num
Sending packet: $QSymbol:400309e0:__pthread_handles_num#93...Ack
Packet received: qSymbol:__pthread_handles
Sending packet: $QSymbol:4002c9e0:__pthread_handles#16...Ack
Packet received: qSymbol:pthread_keys
Sending packet: $QSymbol:40031260:pthread_keys#ce...Ack
Packet received: qSymbol:__linuxthreads_pthread_sizeof_descr
Sending packet: $QSymbol::__linuxthreads_pthread_sizeof_descr#ba...Ack
Packet received: qSymbol:__linuxthreads_pthread_keys_max
Sending packet: $QSymbol:4002b9a0:__linuxthreads_pthread_keys_max#0d...Ack
Packet received: qSymbol:__linuxthreads_pthread_threads_max
Sending packet: $QSymbol:4002b960:__linuxthreads_pthread_threads_max#11...Ack
Packet received: qSymbol:__pthread_threads_debug
Sending packet: $QSymbol:400336f4:__pthread_threads_debug#5b...Ack
Packet received: qSymbol:__pthread_sig_debug
Sending packet: $QSymbol:40031250:__pthread_sig_debug#78...Ack
Packet received: qSymbol:__pthread_sig_cancel
Sending packet: $QSymbol:4003124c:__pthread_sig_cancel#09...Ack
Packet received: qSymbol:__pthread_sig_restart
Sending packet: $QSymbol:40031248:__pthread_sig_restart#7d...Ack
Packet received: OK
Note that the symbol __linuxthreads_pthread_sizeof_descr is requested
but the request is not satisfied. GDB replies with a packet that repeats
the name of the symbol, but with an empty value. The target has to remember
not to request this symbol again until a subsequent shared library is loaded,
or else we would get into a loop.