Re: [PATCH v2 2/2] This patch adds support to debug thread local variables defined in shared libraries in AIX.

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

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

>For global-dynamic/local-dynamic (R_TLSM): scan the .loader section
>for the R_TLSM relocation, read the 8-byte mod_id from the
>inferior's TOC, and dereference it as a TP-relative pointer to
>the per-thread block, then add the intra-module variable offset.

This is certainly more general than the original attempt, but ...

 /* Match: the loader symbol's l_value equals the XCOFF static symbol
    value that GDB received as 'sym_offset'.  For R_TLS and R_TLS_IE
    this is the TP-relative offset baked in at link time.  For R_TLS_LD
    this is the within-module variable offset.  */
 if ((CORE_ADDR)(int64_t) ldsym.l_value != sym_offset)
  continue;

... I don't this logic can work.  For the interesting case
(non-initial-exec modules), the sym_offset is *relative* to
the current module, which means that it does not at all
uniquely identify the symbol.

If you have two dynamic libraries, both defining a single
TLS symbol, they will both get offset 0.  If you try to look
up a particular symbol in the relocation section using the
above logic, it will just look for offset 0 - but that could
randomly hit either of the two variables and therefore
result in the wrong module ID.


If you want to definitively identify the module ID of a
dynamic library from the relocations performed by the loader,
I think there's really only two options:
- if there is a R_TLSML in that library, it must resolve to
  the current module ID (or 0 if it is actually initial-exec)
- otherwise, you need to scan all R_TLSM relocations in all
  modules and check whether the *name* associated with the
  relocation is found in the library you're interested in
  (respecting search order); if yes, that's the module ID
  for that library (or 0 for initial-exec)

That may be a bit inefficient, but I'm not really seeing
any better option here.


On the positive side, this means you can do the whole reloc
scanning fully in the fetch_tls_load_module_address hook
(since you only need the objfile - the offset doesn't help
you anything anyway), and simply return the module ID from
that hook.  (That means you could even cache the module ID
in a per-objfile data structure to pay the price only once.)


Bye,
Ulrich