From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
To: "akamath996@gmail.com" <akamath996@gmail.com>,
"tom@tromey.com" <tom@tromey.com>,
"simon.marchi@polymtl.ca" <simon.marchi@polymtl.ca>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
SANGAMESH MALLAYYA <sangamesh.swamy@in.ibm.com>,
PRAJWAL B MEHENDARKAR <PRAJWAL.B.MEHENDARKAR@ibm.com>,
Aditya Kamath <Aditya.Kamath1@ibm.com>
Subject: Re: [PATCH v1 2/2] Add TLS support for shared libraries in AIX
Date: Wed, 5 Aug 2026 15:16:07 +0000 [thread overview]
Message-ID: <ee38b9322a36df76ac44f724369176952e1257b8.camel@de.ibm.com> (raw)
In-Reply-To: <20260803105911.74857-2-akamath996@gmail.com>
Aditya Vidyadhar Kamath <akamath996@gmail.com> wrote:
>For initial-exec (R_TLS_IE): read the runtime TP-relative offset from
>the .loader section TOC slot written by the AIX loader, returning
>it with bit 0 set as a sentinel so get_thread_local_address() uses
>it directly without re-adding the static symbol value.
>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 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.
Bye,
Ulrich
next prev parent reply other threads:[~2026-08-05 15:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 10:59 Aditya Vidyadhar Kamath
2026-08-05 15:16 ` Ulrich Weigand [this message]
2026-08-10 10:23 ` Aditya Kamath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee38b9322a36df76ac44f724369176952e1257b8.camel@de.ibm.com \
--to=ulrich.weigand@de.ibm.com \
--cc=Aditya.Kamath1@ibm.com \
--cc=PRAJWAL.B.MEHENDARKAR@ibm.com \
--cc=akamath996@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=sangamesh.swamy@in.ibm.com \
--cc=simon.marchi@polymtl.ca \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox