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

[Andrew Burgess <aburgess@redhat.com>]

Kevin Buettner <kevinb@redhat.com> writes:

> 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.  (Though 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.40.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.
>
> This 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.
>

I too have skimmed this series.  Other than my concern about the svr4
function being leaked outside of solib-svr4.c, which I think might break
some targets, and maybe should be addressed, I think getting this
merged would great.

Thanks for working on this.

Andrew