Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets

[Luis Machado <luis.machado@arm.com>]

On 4/18/25 19:36, Kevin Buettner wrote:
> I plan on pushing this series late next week (on or around April 25)
> unless there are objections.
> 
> Kevin
> 
> On Fri,  4 Apr 2025 16:37:31 -0700
> Kevin Buettner <kevinb@redhat.com> wrote:
> 
>> This series of commits adds internal TLS lookup support to GDB for the
>> following Linux target architectures: x86_64, aarch64, ppc64, s390x,
>> and riscv.  When available, libthread_db support for TLS lookup is
>> still preferred/used since it should be more accurate.  This means
>> that existing TLS support will still work as it did before - this new
>> TLS support will only be used when libthread_db TLS support is not
>> available.  That said, it is possible to force internal TLS support to
>> be used via a new maintenance command.
>>
>> Three of the commits in this series provide knowledge about how to
>> translate link map addresses to module ids and how to traverse various
>> TLS data structures.  The latter problem is broken into two parts,
>> one which applies to all Linux architectures, and a second which
>> adds architecture specific knowledge about TLS data structures.
>>
>> Translating link map addresses to module ids is tricky.  In theory,
>> the module id is available in the link map data structure, but it's
>> not part of the ABI.  I ended up implementing two mechanisms for
>> doing this mapping, one for MUSL, and one for GLIBC.  For both of
>> these, I think the method that I used is less fragile than attempting
>> to use an offset to the module id field for current versions of these
>> libraries.
>>
>> Traversing TLS data structures starts with obtaining the value of the
>> thread register (or registers for S390X), then finding the field
>> containing the DTV (dynamic thread vector) address within the TCB
>> (thread control block), then using the module id as an index into the
>> DTV in order to obtain the TLS block.  For some architectures, the
>> MUSL C library requires that a final adjustment be made to obtain the
>> actual address of the TLS block.
>>
>> This patch set also shows how internal TLS support might be added for
>> i386, however, due to problems with accessing the gsbase register, it
>> doesn't work, so the commit which adds this potential support is then
>> immediately deleted in the next commit.  The point of doing this is to
>> make it available in our git repo to anyone who wishes to work on i386
>> support.  IMO, it's not worth doing without also doing corresponding
>> ptrace work in the kernel.  I think this would have been worth doing
>> back in the i386 heyday, but is not worth doing now.  That said,
>> should anyone wish to look into it, the commit showing how to do it
>> will be in our repo as well as on the mailing list.
>>
>> The details for traversing the TLS data structures differ not only
>> between architectures, but also depends upon the C library with which
>> the executable being debugged has been linked.  The internal TLS
>> support in this series is known to work with GLIBC versions 2.27 thru
>> 2.41.9000 and MUSL versions 1.1.24, 1.2.3 and 1.2.5.  For MUSL, the
>> support provided by this series provides new debugging functionality
>> that didn't exist before - it will now be possible to examine TLS
>> variables in programs linked against MUSL.  (It didn't work before
>> due to MUSL not implementing the libthread_db library.)
>>
>> I've done regression testing on recent Fedora versions for all five
>> architectures.  Bugs were found and fixed during that testing.
>>
>> Once that was done, I did even more testing, using a limited number of
>> tests.  These include the new tests that I've added, plus those tests
>> with which regression testing identified some problems.  The list is:
>>
>> TESTS="gdb.base/tls-dlobj.exp gdb.base/tls-nothreads.exp \
>>        gdb.base/tls-multiobj.exp gdb.threads/tls.exp \
>>        gdb.server/no-thread-db.exp"
>>
>> I tested using targets:
>>
>>   unix, native-gdbserver, native-extended-gdbserver,
>>
>> and, for x86_64 targets, I also tested with 32-bit variants:
>>
>>   unix/-m32, native-gdbserver/-m32, and native-extended-gdbserver/-m32
>>
>> I also tested with no CC_FOR_TARGET (which defaults to gcc),
>> CC_FOR_TARGET=musl-gcc, and CC_FOR_TARGET=clang.  On Fedora, using
>> CC_FOR_TARGET=musl-gcc causes the program and libraries to be compiled
>> with gcc, but linked against the MUSL C library.  I didn't use this
>> option on non-Fedora machines, though my Void linux testing tested
>> using the MUSL library since that's what's installed in that test
>> environment.
>>
>> I also ran additional tests using check-read1 for combos with no
>> CC_FOR_TARGET.
>>
>> Using all sensible combinations of the above, I tested on 13 machines / 5
>> architectures:
>>
>>   x86_64 / Fedora 28 / glibc-2.27
>>   x86_64 / Fedora 34 / glibc-2.33 / musl-libc-1.2.3
>>   x86_64 / Fedora 35 / glibc-2.34 / musl-libc-1.2.3
>>   x86_64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>>   x86_64 / Fedora 41 / glibc-2.40 / musl-libc-1.2.5
>>   x86_64 / rawhide (fc42) / glibc-2.40.9000 / musl-libc-1.2.5
>>   x86_64 / OpenSuse Leap 15.5 / glibc-2.31 / no musl
>>   x86_64 / Ubuntu 22.04 / glibc-2.35 / no musl
>>   x86_64 / void - 2024-03-14 / no glibc / musl 1.1.24
>>
>>   aarch64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>>   riscv / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>>   ppc64le / Fedora 41 / glibc-2.40 / musl-libc-1.2.5
>>   s390x / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>>
>> The point of testing old Fedora releases is to be able to test
>> older glibc versions.  In particular glibc-2.33 and earlier
>> had pthread functionality split into libpthread.so while glibc-2.34
>> and later place it into libc proper.
>>
>> All of the testing went well except on riscv and s390x with
>> CC_FOR_TARGET=clang.  That's six test runs total, and they each show
>> 799 FAILs.  The test results show that riscv mostly prints the wrong
>> answer and that s390x shows output like "Cannot access memory at
>> address 0x3fff8d494e8".  But this happens regardless of whether
>> internal TLS support or libthread_db support is used.  I think it's
>> likely that it's a clang bug of which I can do nothing about (aside
>> from filing a bug report).
>>
>> The v2 series fixed some problems in the gdb.base/tls-dlobj.exp test
>> found by the Linaro regression tester, tweaked a comment in
>> aarch64-linux-tdep.c, included a discussion of what TLS is in the
>> documentation patch, and renamed 'set force-internal-tls-address-lookup'
>> to be a maintenance command.  Thanks to Luis and Eli for their
>> feedback on the v1 series.  Thanks, too, to Linaro for regression
>> tester feedback.
>>
>> The v3 series made corrections to the documentation, as requested by
>> Eli.
>>
>> The v4 series fixed some other documentation nits.
>>
>> The v5 series moves the "target has registers" check and output of a
>> suitable error message into target_translate_tls_address.  In v4 and
>> earlier, this error check was being performed at some of the call
>> sites for target_translate_tls_address.  The entire series has been
>> retested as described above, though on a subset of targets.  All
>> five architectures (x86_64, aarch64, ppc64le, s390x, and riscv) have
>> all been tested though.  Additionally, testing has been done on
>> machines with recent glibc versions in addition to a version of glibc
>> which predates 2.34, specifically glibc-2.33.
>>
>> This v6 series addresses a problem found by Andrew Burgess: In his
>> review of the v5 series, Andrew observed that not all Linux targets
>> use SVR4 shared library support, and therefore can not depend on
>> extern functions defined in solib-svr4.c to be available.  One example
>> is FR-V Linux which uses solib-frv.c in order to provide support for
>> the FDPIC shared library ABI.  I addressed this problem by moving
>> non-architecture-specific TLS code out of linux-tdep.c (which is used
>> by all Linux targets) into a new file named svr4-tls-tdep.c.  In order
>> to make sure that svr4-tls-tdep.o is linked into the correct targets
>> (when not doing a --enable-targets=all configuration), svr4-tls-tdep.o
>> has been added to the target_obs definition in gdb/configure.tgt for
>> the various target patterns which should have internal TLS lookup
>> support.  This change, which moves the generic internal TLS support
>> out of a linux specific file into a new file, makes this TLS support
>> infrastructure available to other targets which use SVR4 shared libary
>> support, whether they're Linux targets or not.  For example, GDB's
>> GNU/Hurd support or perhaps BSD support could now use these
>> mechanisms.  (For the latter, I suspect that we'd need to teach it
>> about BSD's libc.)
>>
>> Kevin Buettner (11):
>>   Don't attempt to find TLS address when target has no registers
>>   Allow TLS access to work in gdb.server/no-thread-db.exp
>>   Track and fetch TLS module ids for MUSL and GLIBC
>>   Implement internal TLS address lookup for select Linux targets
>>   Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
>>   Internal, but disabled, TLS support for i386
>>   Delete disabled i386 internal TLS support
>>   New test - gdb.base/tls-nothreads.exp
>>   New test - gdb.base/tls-multiobj.exp
>>   New test - gdb.base/tls-dlobj.exp
>>   Add TLS NEWS entry and document 'set
>>     force-internal-tls-address-lookup' command
>>
>>  gdb/Makefile.in                           |   3 +
>>  gdb/NEWS                                  |  20 ++
>>  gdb/aarch64-linux-tdep.c                  |  56 ++++
>>  gdb/amd64-linux-tdep.c                    |  38 +++
>>  gdb/configure.tgt                         |  11 +-
>>  gdb/doc/gdb.texinfo                       |  50 +++
>>  gdb/findvar.c                             |   3 +-
>>  gdb/linux-tdep.c                          |   1 +
>>  gdb/minsyms.c                             |   3 +-
>>  gdb/ppc-linux-tdep.c                      |  63 ++++
>>  gdb/riscv-linux-tdep.c                    |  79 +++++
>>  gdb/s390-linux-tdep.c                     |  44 +++
>>  gdb/solib-svr4.c                          | 207 +++++++++++-
>>  gdb/solib-svr4.h                          |  12 +
>>  gdb/svr4-tls-tdep.c                       | 256 +++++++++++++++
>>  gdb/svr4-tls-tdep.h                       |  59 ++++
>>  gdb/target.c                              |  16 +-
>>  gdb/target.h                              |   8 +-
>>  gdb/testsuite/gdb.base/tls-common.exp.tcl |  50 +++
>>  gdb/testsuite/gdb.base/tls-dlobj-lib.c    |  87 +++++
>>  gdb/testsuite/gdb.base/tls-dlobj.c        | 311 ++++++++++++++++++
>>  gdb/testsuite/gdb.base/tls-dlobj.exp      | 378 ++++++++++++++++++++++
>>  gdb/testsuite/gdb.base/tls-multiobj.c     |  89 +++++
>>  gdb/testsuite/gdb.base/tls-multiobj.exp   | 230 +++++++++++++
>>  gdb/testsuite/gdb.base/tls-multiobj1.c    |  26 ++
>>  gdb/testsuite/gdb.base/tls-multiobj2.c    |  26 ++
>>  gdb/testsuite/gdb.base/tls-multiobj3.c    |  26 ++
>>  gdb/testsuite/gdb.base/tls-nothreads.c    |  57 ++++
>>  gdb/testsuite/gdb.base/tls-nothreads.exp  | 248 ++++++++++++++
>>  gdb/testsuite/gdb.server/no-thread-db.exp |   4 +-
>>  gdb/testsuite/gdb.threads/tls.exp         |   2 +-
>>  31 files changed, 2446 insertions(+), 17 deletions(-)
>>  create mode 100644 gdb/svr4-tls-tdep.c
>>  create mode 100644 gdb/svr4-tls-tdep.h
>>  create mode 100644 gdb/testsuite/gdb.base/tls-common.exp.tcl
>>  create mode 100644 gdb/testsuite/gdb.base/tls-dlobj-lib.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.exp
>>  create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.exp
>>  create mode 100644 gdb/testsuite/gdb.base/tls-multiobj1.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-multiobj2.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-multiobj3.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.c
>>  create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.exp
>>
>> -- 
>> 2.48.1
>>
> 

Do you have an updated series that applies cleanly on master? Looks
like there are some conflicts at the moment.