Re: [PATCH v1 2/2] Add TLS support for shared libraries in AIX

[Aditya Kamath <Aditya.Kamath1@ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]

Hi Ulrich and community members,

>This is an interesting approach, which is quite different from what
>Linux is doing.   The one question/concern I have this: are these
>relocations present in the module where the TLS symbol is *defined*,
>or rather in the module where the TLS symbol is being *used*.  On
>Linux (ELF), it would be the latter - but I don't know all the AIX
>(XCOFF) details here.

>If it is the latter, then this approach has the drawback that the
>debugger can only access symbols that are also accessed somewhere
>within the program being debugged (in fact, with the current patch,
>only symbols that are used in the same module they are defined in).
>With the approach used on Linux, it is in principle possible to
>access TLS symbols whether they are used or not.  (If there's no
>better way to implement this, that of course may still a limitation
>that can be accepted.)

>Either way, it would be good to add test cases for the various
>scenarios.


Yes, we are on the same page here.

Let me take this opportunity to explain more and give more information.


# cat tls_lib.c


#include <stdio.h>


_Thread_local int lib_tls_var = 42;


int
lib_get_tls (void)
{
  return lib_tls_var;
}

void
lib_set_tls (int val)
{
  lib_tls_var = val;
}


Assume this is my C code that I am using to create tls_lib.so

The way I am computing TLS variable address currently is


dump -X64 -Hr tls_lib.so | grep "0x0021\|0x0024"
        0x110000528  0x00000018     0      0  0x003f    0x0021

The above gives me 0x110000528 - reloc type 0x24 (R_TLSM, global-dynamic) or 0x21 (R_TLS_IE, initial-exec) which is my static TOC slot address.


CORE_ADDR toc_addr = ldrel.l_vaddr + objfile->data_section_offset ();

The above line the patch is doing this where ldrel.l_vaddr =  0x110000528.


bash-5.3# dump -X64 -tv tls_lib.so | grep lib_get_tls
[16]    m   0x100000480     .text     1  extern                    .lib_get_tls
[20]    m   0x1100004f8     .data     1  extern                    lib_get_tls

This gives me static address lib_get_tls.


/home/aditya/binutils-gdb/gdb/gdb ./tls_test
Reading symbols from ./tls_test...
(gdb) break tls_main.c:36
Breakpoint 1 at 0x100000a78: file tls_main.c, line 36.
(gdb) r
Starting program: /home/aditya/tls_test/tls_test
main: lib_tls_var initial = 42
[New Thread 258 (tid 131072299) (id 2)]
[Switching to thread 2 (Thread 258 (tid 131072299))]

Thread 2 hit Breakpoint 1, thread_runner (arg=0x1) at tls_main.c:36
36    volatile int bp_here = 0; (void)bp_here;
(gdb) p/x &lib_get_tls
$1 = 0x900000000e42480

The above is the dynamic address of lib_get_tls () inside the shared library.


(gdb) x/1gx 0x110000528 + 0x900000000e42480 - 0x1100004f8
0x900000000e424b0 <lib_set_tls>:      0x9061fff48061fff4

So the objfile->data_section_offset () is helping me to get 0x900000000e42480 - 0x1100004f8 which is the offset to the data section.

So, the plan is to inspect the link time symbol table for the TOC entries associated with the TLS variable in its defining module. From there identify the load time address of the appropriate TOC entries and then use the values to perform TLS address calculations.

Unfortunately, compilers [GCC or clang] on AIX will not generate the TOC entries in a translation unit if the variable is unreferenced.

So, we cannot be in sync with the way Linux via ELF does. In Linux DTV lookup can be done for unreferenced variables. Even in stripped binaries TLS debugging will not work in AIX with this approach.

Until this is implemented in both compilers, I would like to propose this method so AIX users can debug thread local variables.

Let me know what the community thinks.

Have a nice day ahead.

Thanks and regards,
Aditya.



[-- Attachment #2: Type: text/html, Size: 12865 bytes --]