This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB support for thread-local storage


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]