Re: GDB support for thread-local storage

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:
> > Jim Blandy <jimb@redhat.com> writes:
> >
> >> Andrew Cagney <ac131313@cygnus.com> writes:
> >
> >> > 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.
> >
> >> 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.
> > What I wrote is incorrect.  HP does handle TLS in shared libraries.
> > But in their arrangement, every thread-local variable lives at a
> > offset from register CR27, and GDB can compute that offset at
> > symbol-reading time.
> > I think this means that they don't address a lot of the issues that
> > the IA-64 / SPARC / Red Hat proposal does.  I don't see how you'd
> > handle dlopen'd libraries or lazy allocation in their scheme.
> 
> I don't know.  HP people do monitor this list so may be able to answer.
> 
> > But in any case, HP's gdbarch method for finding thread-local storage
> > would be very simple: just add the offset to CR27, and there's your
> > address.
> 
> BTW, why, in your propsal, is the offset incorporated into the address
> that is returned - rather than getting the base address and then
> adding the offset - more like HP did.

That's me imitating a rather weird quirk in the way the TLS run-time
implementation works.  But if you look at my Dwarf 2 sketch proposal,
we can't do it that way.  We need something that gives us the base
address.  So the way HP does it is pretty much the way we'll do it,
except for the assumption that the base address is in a register.