From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kPeUOjBv8Ge1GicAWB0awg (envelope-from ) for ; Fri, 04 Apr 2025 19:45:52 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UR96I+CM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E22541E0C3; Fri, 4 Apr 2025 19:45:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DF41E1E0C0 for ; Fri, 4 Apr 2025 19:45:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7644B3846466 for ; Fri, 4 Apr 2025 23:45:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7644B3846466 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UR96I+CM Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id E86F4385AC31 for ; Fri, 4 Apr 2025 23:43:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E86F4385AC31 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E86F4385AC31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743810234; cv=none; b=j4ZLx7OhaxJvemgId/XLUpjoX5YagZkF6yrsrZ6vScjgWVX28WABADgkgIB/d0QyiHmw7fqAJ+r94ySjUmIH5gnmXj9PsopD9JYKb/pgwKPqpwWTX9pdQM8Mxe8zgAPGO9qMMlJOq470yMLFcyrecErPZ/yVs33u9mrVIuFpDQ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743810234; c=relaxed/simple; bh=+a9E4L2oLDpGu254zHEMKZ5qQplTiPKgwXzQK8hJHW8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=SRYuol0kZlMozzVMoworYOHqjlRepuXNfCSpZl4LuRssKOn8KH8D/+ZVmHdUTlqjuedoj4K+MpSA84T45q3/scTmWwCQkRHNrz+/KKiX/HEQ7BUPnW3y45bjW7ObzbwmF6mmQd3v+wm+daJBytIfT1BdPhK9cmr+z3jYlF4huBY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E86F4385AC31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743810233; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=XA577SAS6n8H5nmCzPcWW2Ir/q0nUrJKh4OGXS/M5rc=; b=UR96I+CMeRPbK6HRXeeCmzePFl3C6dXrm8W8xQOfnQoZnJshm64PhfaqLuHtsUCW/fzUX8 uYRozkAwegfJcyxGHIFGgfgIg8uPaOTMUd3bbMuwPwLaJ7FC4sDAqlmLsDL4bv2VrK8u4H XEmSDzDRNFmxW3ZTTMtwnZI1toQz60E= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-16-5IBzp8QLMzOLwMhexIPnDA-1; Fri, 04 Apr 2025 19:43:52 -0400 X-MC-Unique: 5IBzp8QLMzOLwMhexIPnDA-1 X-Mimecast-MFC-AGG-ID: 5IBzp8QLMzOLwMhexIPnDA_1743810231 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5438C1955BC1 for ; Fri, 4 Apr 2025 23:43:51 +0000 (UTC) Received: from f42-1.lan (unknown [10.22.88.7]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7D8B61955BC2; Fri, 4 Apr 2025 23:43:50 +0000 (UTC) From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Kevin Buettner Subject: [PATCH v6 00/11] GDB-internal TLS support for Linux targets Date: Fri, 4 Apr 2025 16:37:31 -0700 Message-ID: <20250404234324.1931302-1-kevinb@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: hfZAdpSVS0zcI7o-ch1Xbpqqz21g3HcJ8g0vp-HzK8A_1743810231 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org 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