Re: RFC: initial TLS patch

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > But, to me, it seems like this interface explicitly reflects the
> > quirks of the TLS implementation.  What if some other TLS
> > implementation requires, say, relocs to be applied to the
> > initialization image?  What if some processor with lots of registers
> > puts small TLS variables in registers?  (You could have register-sized
> > relocs, and let the static linker assign the register number.
> > Dynamically linked code couldn't do this, but that's okay.)
> 
> 
> > Maybe that's contrived.  But given how hairy TLS seems to be, I expect
> > to see some variety in the implementations.  And each time we
> > encounter another variant, then this interface will need to again be
> > expanded to accomodate that.  This target method will end up showing
> > every possible way anyone has ever constructed a thread-local value.
> 
> For all we know, that thread implementation could be so incompatible
> with what you're adding that they need to add yet another LOC.  As I
> noted before:
> 
>  > Having it return something more complicated like a ``struct value''
> can be left to the person that actually needs the mechanism - I figure
> they will be in a better position to determine exactly what mechanism
> is needed.
> 
> I think this is very important.  To apply the old engineering motto -
> K.I.S.S.

Yes, of course.  And I think returning a `struct value' is the simpler
thing to do.  :)

Right now, here's the interface which would accomodate the
possibilities we know of today using the simplest datatypes:

        CORE_ADDR (*to_get_thread_local) (ptid_t thread,
                                          struct objfile *load_module,
                                          CORE_ADDR offset,
                                          int *init_image);

Explaining what `init_image' means, and how to use CORE_ADDR in each
case, and why it must be so, basically requires explaining the whole
lazy thread-local storage allocation model.  I can do that, but it
seems more complex to me than explaining:

        struct value *(*to_get_thread_local) (ptid_t thread,
                                              struct objfile *load_module,
                                              CORE_ADDR offset,
                                              struct type *type);

This is easy: "Return the object of type TYPE at offset OFFSET in
THREAD's thread-local storage for LOAD_MODULE."  One has to point out
that thread-local storage blocks are both per-thread and per-load
module --- the cartesian product --- but then you're done.

At this point, I feel like I've explained my position about as well as
I can, and you're not persuaded; since Michael S. hasn't said
anything, I assume he isn't either.  Since I don't think it'll be so
bad to do it the way you suggest, I'll go with that, and we'll see how
it goes.

> I also noted that:
> 
>  > Perhaphs there should be a separate ``struct location'' object?
> 
> I'll post this to gdb@.

See, this makes no sense to me.  If a `struct value' is too high-level
a thing for a target method to return, why is `struct location' any
different?  The two seem part of the same structural layer to me.

*shrug*