From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eFvoNNqbAmhLQToAWB0awg (envelope-from ) for ; Fri, 18 Apr 2025 14:37:14 -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=FZEeNbCU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D36121E0C3; Fri, 18 Apr 2025 14:37:14 -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 B67B91E05C for ; Fri, 18 Apr 2025 14:37:13 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4FFE83858C60 for ; Fri, 18 Apr 2025 18:37:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4FFE83858C60 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=FZEeNbCU Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 94F223858D21 for ; Fri, 18 Apr 2025 18:36:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 94F223858D21 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 94F223858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745001395; cv=none; b=CBbO5k1/hgwTiXpW/24LuHFVwIUKIgKw90QEm+aXhJo4d67BNKezBL4nEZxLHMssa0iTbgrxhEfBymaEx/ajuubkcQRSWQO7sbO9bsSS3elog2JdvTNye5M49ou0tYYIeOgCgG1IgFNhLT/gkdK6J0fkyrpiBNsxADSFbWM1O1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745001395; c=relaxed/simple; bh=YM8AtjEzW+n9mGvkGNvqZX9wib169fr7EtH3b8ObL8s=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=TUJa/1m5y0OoruGP3K8DvGFigD0tbwAMXGrCBMFSWxTgRzbGLnSL3l1qSy0cl9zk6IOqRbXZ8sFk0dyqprkdzdaQShWJtSpAe/es3TrhUv7MUYmxUZNnCpgFPR8dgc7y4Y7YZWeRu265YOz9LRi7unJZ9RN9fCPzijnsKfTlYuI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 94F223858D21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745001395; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DOIVqpYAFrqNDOktRPJ83JYJDiSS/Vo9B1o+5GD7u3Y=; b=FZEeNbCU/gGdYqu12xCB+AZA6IaOaRdaZUwlo1sVTiQcw0JNJfG5657suc3i9E5u/Q8aHg qGNISTNWM8u7xkL1LHf4TXTmrV08ottmT1hCGQJO4h8LshCuTgGs454QGMMOdZQf1A3vNT mfIwLz/GiApvMdPr9EiLLi1mwrgGVDA= Received: from mx-prod-mc-04.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-683-La5K0jWWO3-yFdqhBMhEEQ-1; Fri, 18 Apr 2025 14:36:34 -0400 X-MC-Unique: La5K0jWWO3-yFdqhBMhEEQ-1 X-Mimecast-MFC-AGG-ID: La5K0jWWO3-yFdqhBMhEEQ_1745001393 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2D6931955DC5 for ; Fri, 18 Apr 2025 18:36:33 +0000 (UTC) Received: from f41-zbm-amd (unknown [10.22.80.11]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 87829180045C for ; Fri, 18 Apr 2025 18:36:32 +0000 (UTC) Date: Fri, 18 Apr 2025 11:36:22 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets Message-ID: <20250418113622.2bf410b7@f41-zbm-amd> In-Reply-To: <20250404234324.1931302-1-kevinb@redhat.com> References: <20250404234324.1931302-1-kevinb@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: h8S_Lh59CI2PEACX7pF4KgAh18cdHNaXKyEIlzsV9rY_1745001393 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 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 >