Re: GDB support for thread-local storage

[Jim Blandy <jimb@redhat.com>]

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?