--- Begin Message ---
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.
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.
Given that hpread.c hard-codes a reference to the macro CR27_REGNUM,
which is only defined in config/pa/tm-hppa.h, I assume that hpread.c
is only used in PA targets. The PA hasn't been multi-arched, so I
assume it's going away.
So, does anyone care if I break the hpread.c code?
--- End Message ---