This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 20 Jun 2002 21:35:25 -0400
- Subject: Re: GDB support for thread-local storage
- References: <20020619160004.38A625EA11@zwingli.cygnus.com>
I've posted a note to the Dwarf mailing list, describing the
DW_OP_push_tls_address approach, and saying that we'll experiment with
this as a GNU extension to Dwarf and write back when we've actually
got something working.
Hmm, would you be able to post the prososal here?
For STABS, we can simply invent a new symbol type, whose value is the
offset within the thread-local storage block for the current thread
for the module containing the stab. I haven't written up a real
proposal for STABS yet.
On Linux, Ulrich Drepper has added the following function to
libthread_db:
Has solaris, or even MS, done anything in this area? The
LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you may
want to look at what HP/UX is getting up to.
If you're not convinced it should be a target method, consider this:
Remember that libthread_db isn't clean for cross-debugging. It's a
target library. So at the moment, there are cases where gdbserver
loads and uses libthread_db, not GDB itself. In those cases, the
tls_get_addr request needs to be sent across the network connection to
gdbserver, td_thr_tls_get_addr needs to be invoked there, and the
answer needs to be sent back. By making tls_get_addr a target method,
it's easy for the remote protocol layer to provide its own definition
of the method and send a packet across for the request.
Similar to this, both SOFTWARE_SINGLESTEP and hardware breakpoints are
ment to be implemented with support from both the target vector and the
architecture vector. By doing that, a sequence like:
can target single step?
yes, step target
else
use architecture to software singlestep target
can be implemented (in both cases it isn't so it can't, ulgh).
However, in the case of the above, is the architecture method needed?
Given that th only thing implementing this will be the above GNU/Linux
thread-db library, and GDB's linux thread code will know to call that
directly.
BTW, what happens if the target doesn't have execution (i.e. a corefile).
Andrew
(Use thread_local_static rather than thr_tls in function names)