This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
Andrew Cagney <ac131313@cygnus.com> writes:
> > 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.
I didn't see anything in the Solaris "Stabs Interface Manual"
(distributed with the Solaris toolchain, not publicly) about it.
HP implements something much simpler. It doesn't deal with
thread-local storage in PIC code; the initialization image is laid out
completely at static link time. It's thread-local storage in
dynamically loaded libraries that introduces all the hair.
> > 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).
Yes, I remember you saying this before; I was trying to follow your
lead here.
> 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.
I don't think that's so. As I say, Uli is pretty much just following
what the IA-64 and SPARC people have done for their ABI's, and
introducing a new scheme for the IA-32. So we should expect this
feature to crop up on other platforms.
As far as the gdbarch method is concerned, I dunno. It's true that
nobody is actually going to define the method at the moment. But I
don't see why embedded ABI's wouldn't want to support __thread; the
whole point is that __thread can be faster and have less overhead than
the pthreads alternative, which (it seems to me) would make it very
attractive to the embedded world. So I would expect the gdbarch
method to be used for the first embedded ABI that supports __thread.
Should we put off adding the gdbarch method until someone is actually
going to define it?