Re: GDB support for thread-local storage

Andrew Cagney
2002-06-22T03:24:30Z

> 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