Re: GDB support for thread-local storage

[Andrew Cagney <ac131313@cygnus.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.

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.

Andrew