Re: GDB support for thread-local storage

[Jim Blandy <jimb at redhat dot com>]

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?