This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: initial TLS patch
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*