From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qCZGMfJvW2cDzBEAWB0awg (envelope-from ) for ; Thu, 12 Dec 2024 18:21:22 -0500 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=Z4b9iStx; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C66701E097; Thu, 12 Dec 2024 18:21:22 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) 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=unavailable autolearn_force=no version=4.0.0 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 0157E1E05C for ; Thu, 12 Dec 2024 18:21:22 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8749A385840A for ; Thu, 12 Dec 2024 23:21:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8749A385840A 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=Z4b9iStx 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 68A763858D35 for ; Thu, 12 Dec 2024 23:20:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 68A763858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 68A763858D35 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=1734045644; cv=none; b=se0H/jFW6cQTJMjfwzrSUXFIvZkv6q5bFU9rn3j7roeLzI/eZAaTi9bkSyR4+thJlbrllVVlnrnvQudNBu6y2O3oBoNK2lA6rhJFMJXi5JnN090fK2U3VzotkcYXAHMPWaiK361Lmr7ldn7nP6e9dpSV3mdSE6+TLHKegSDouCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1734045644; c=relaxed/simple; bh=vy9Gm/qXze4N4qJSQaO/NesnTXb0zm/fdEtbiD5pQzI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=MxEBQEPsWMr5BWClsvhiYj6ZNmeuTIvkmnDSTdMA02h6XUslmCy1OQQ/IiCBSwDHv9bEFEKuAFOkwaTcK37BacWRzWEtayCCIiIOytF4LdSTzc/AaOTNnMTqTN9KoGL56p8HzQ5ec8BF7MSJYKk6pIXOkVNkuunndOZ21TYmsRQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68A763858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734045644; 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=fpManKeLDzK7VzmAAS/ja/aHEwSw9QSkIaEGuPJmNWo=; b=Z4b9iStxgmIbplj+rVJrC++2tsOTcV+05W9DncYOi4PSdmA2NhgWrrPlXZGbRJp9uyEjL/ GVTjdME2PPisp/WOvjlSw2FVNvRPAScMaqiUN1i+aJF0jAlDdBwkrDMYn9y6SKSkA0woPu 0OIf2l///ksKuEBl/+mD0RvuZS5fYYY= 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-349-0aO2xxblM36PSBhGpxG4tQ-1; Thu, 12 Dec 2024 18:20:42 -0500 X-MC-Unique: 0aO2xxblM36PSBhGpxG4tQ-1 X-Mimecast-MFC-AGG-ID: 0aO2xxblM36PSBhGpxG4tQ Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 DEB7819560B3 for ; Thu, 12 Dec 2024 23:20:41 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.80.92]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 584B130044C1 for ; Thu, 12 Dec 2024 23:20:41 +0000 (UTC) Date: Thu, 12 Dec 2024 16:20:36 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [PATCH v4 00/11] GDB-internal TLS support for Linux targets Message-ID: <20241212162036.311ca702@f40-zbm-amd> In-Reply-To: <20241106192517.206988-1-kevinb@redhat.com> References: <20241106192517.206988-1-kevinb@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: eVSIloD6M4ogEJ09BWnzIGSmmt8jn2CECqHSqjbe8xU_1734045642 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 Ping (for parts 1 thru 10). On Wed, 6 Nov 2024 12:21:36 -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. (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. > > This v4 series fixes some other documentation nits. > > 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 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/NEWS | 20 ++ > gdb/aarch64-linux-tdep.c | 55 ++++ > gdb/amd64-linux-tdep.c | 37 +++ > gdb/doc/gdb.texinfo | 50 +++ > gdb/findvar.c | 7 +- > gdb/linux-tdep.c | 211 ++++++++++++ > gdb/linux-tdep.h | 36 +++ > gdb/minsyms.c | 8 +- > gdb/ppc-linux-tdep.c | 62 ++++ > gdb/riscv-linux-tdep.c | 78 +++++ > gdb/s390-linux-tdep.c | 43 +++ > gdb/solib-svr4.c | 203 +++++++++++- > gdb/solib-svr4.h | 12 + > 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 +- > 25 files changed, 2347 insertions(+), 7 deletions(-) > 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.46.2 >