Re: [PATCH v4 2/3] Add support for TLS variables in shared libraries on AIX.

[Ulrich Weigand <Ulrich.Weigand@de.ibm.com>]

Aditya Vidyadhar Kamath <akamath996@gmail.com> wrote:

>- module-id 0 is initial-execed shared library where the AIX
>  loader merges all initial-exec modules into one contiguous
>  TLS segment and adjusts each variable's TP-relative offset
>  accordingly.  The link-time XCOFF symbol value does not
>  necessarily equal the runtime offset.  The patch scans
>  the library's R_TLS slots and matches by l_value (unique within
>  one module) to find the slot the loader filled with the actual
>  runtime TP-relative offset, then computes address =
>  tp + runtime_offset.

That last part I suspect still won't work correctly in all cases:

+      /* l_value holds the link-time TP-relative offset.  It is unique
+	 within a module, so matching against static_offset identifies
+	 exactly the right variable.  */
+      if ((CORE_ADDR)(int64_t) ldsym.l_value != static_offset)
+	continue;

Sure, the offset is unique within the module where the TLS variable
is defined.  But you are not actually guaranteed to be within that
module at this point.  In fact, more likely than not, "objfile" at
this point is some *other* module that has a *reference* to the
TLS variable in question - or actually some *other* TLS variable
defined in another module with the same static offset ...

I guess you could again compare names here.  Or else, maybe you can
actually pre-compute the offset earlier: at the point where you find
a R_TLSM relocation referencing a module, and the module ID is zero,
shouldn't there be a R_TLS relocation for that same symbol as well?
If you compare the relocated TOC value for R_TLS with the static
offset of the symbol, that difference should be the (fixed) offset
of the module's TLS block within the merged initial-exec TLS block.

So you could remember a pair of "(module ID; offset)" and then
apply the offset when resolving symbols.  (Maybe the pair can be
encoded more efficiently since you only need the offset if the
module ID is zero.)

I'm not sure how to handle the R_TLSML case - I think if a module
has that relocation, there should also be at least one instance
of an R_TLS_LD to a symbol in the module, and then you could
again compute the block offset.

However, I guess depending on compiler options it might also be
the case that all references to TLS symbols in a given module
happen to only use R_TLS_IE - in that case, you know the module
must be in the initial-exec segment (i.e. module ID zero), and
then again get the offset from the R_TLS_IE relocated value.


Bye,
Ulrich