Re: RFC: initial TLS patch

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> 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.

I also noted that:

> Perhaphs there should be a separate ``struct location'' object?

I'll post this to gdb@.

Andrew