From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nQWjFddtB2drRwgAWB0awg (envelope-from ) for ; Thu, 10 Oct 2024 02:01:59 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=IoPTUXD8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 363E81E356; Thu, 10 Oct 2024 02:01:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 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_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham 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 BA4D11E354 for ; Thu, 10 Oct 2024 02:01:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B22713858C2B for ; Thu, 10 Oct 2024 06:01:56 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 62B3A3858D21 for ; Thu, 10 Oct 2024 06:01:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 62B3A3858D21 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 62B3A3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728540096; cv=none; b=wNZ9ilsyKUqBJhsjqCsmJu7KR4+Mz6Ij6714g2qKqToYKBg7I8lw5rYFhriAa7EdiSFTlcPM+fhwh/H9jB/WaTMEc1Ka+Wp34vjA4NSYLWUJoVmIFcBNoYgHsGFtIhbt/TA7GzIAanP8Gl4HWXfNQ9KTFqtXUERfvl/dAXMl+qs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728540096; c=relaxed/simple; bh=rB/rSNZhCNel3GebDQPTjpoS4CiynK6B8wVkIv4iXt0=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=v0tckOkl6VMvE8VvGOLxDUmQu2KHKWHsNgOFybF3bjgoSx19p1LGtvgzgZIaxOwKNuzWQg0ZWk++UnxCA7ZLK8dbHqFQPmN3nCpfbH/E+7nlMBXgMBwyKxC5Ynyr+xPB2HX7l9iHYd19iNnqGxxZZYrjg32/U1m9k08ZP/cf+DE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1symEu-0006zA-OY; Thu, 10 Oct 2024 02:01:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Am8GD93N5SxchmM5YkW48ifVpTP/ghc2mnXnAs2WQCQ=; b=IoPTUXD8Bbvv xeUTSWZbMAxfdou8Ytv+pmaBKAEsOG1uJfqCMsXYdfMWHA/vENAK4ratsl7XEhWa7UdhLWYYBZp0B taRIYmMfCUWdSVjhkIcOp+hZyGDHDbIkH3N25Vzm5om2aHhzy6OS/CIL/tDTt/bhxqemCi1wQJ5DL sxgpt4GJONncbKnXVSbNOnTOKU2HmXeIcjoW7SSHLDYmX353qhZuhNhTwPMP6o8D+Fnk/vzrmIwJB WOKaU2ouPoGnqhDMH2WYkdjaIPOg9tL3zayJJHmRH4t/FRsy3PEu/V7Pupw8dKmO0kCFWcd/I+iVq j7RjbA0sqqzm7ZOL0KRaxg==; Date: Thu, 10 Oct 2024 09:01:31 +0300 Message-Id: <86iku0339g.fsf@gnu.org> From: Eli Zaretskii To: Kevin Buettner Cc: gdb-patches@sourceware.org In-Reply-To: <20241010022552.47637-12-kevinb@redhat.com> (message from Kevin Buettner on Wed, 9 Oct 2024 19:16:14 -0700) Subject: Re: [PATCH 11/11] Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command References: <20241010022552.47637-1-kevinb@redhat.com> <20241010022552.47637-12-kevinb@redhat.com> 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 > From: Kevin Buettner > Cc: Kevin Buettner > Date: Wed, 9 Oct 2024 19:16:14 -0700 > > --- > gdb/NEWS | 20 ++++++++++++++++++++ > gdb/doc/gdb.texinfo | 17 +++++++++++++++++ > 2 files changed, 37 insertions(+) Thanks. A general comment: I think the documentation changes should include the explanation of the "TLS" acronym and its meaning in the context of debugging. Without saying that much, this piece of documentation makes very little sense, if at all. Another aspect that is missing is how the new commands affect user-level features in GDB. What does it mean to "force TLS lookup", and how does it matter whether the TLS look up is internal or via libthread_db, when a program uses thread-local storage? More generally, what is "TLS address look up" and how it affects debugging multithreaded programs? Note that the current text in the manual mentions libthread_db as a "helper library" for debugging multithreaded programs, but doesn't go into details of what that "help" includes, leaving that vague and unexplained. This addition builds on that description, but it talks about a very specific aspect of supporting threads, and does that without explaining its role. The previous text about libthread_db doesn't help in any way, so we must add some details here, IMO. Some more specific comments follow: > diff --git a/gdb/NEWS b/gdb/NEWS > index 42668cbc057..dcb24eb5248 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -63,6 +63,26 @@ > the return value from the latest "stepOut" command, when > appropriate. > > +* GDB-internal TLS support > + > + ** Linux targets for the x86_64, aarch64, ppc64, s390x, and riscv > + architectures now have GDB-internal support for TLS address > + lookup in addition to that traditionally provided by the > + libthread_db library. This internal support works for programs > + linked against either the GLIBC or MUSL C libraries. For > + programs linked against MUSL, this new internal support provides > + new debug functionality, allowing access to TLS variables, due to > + the fact that MUSL does not implement the libthread_db library. > + Internal TLS support is also useful in cross-debugging > + situations, debugging statically linked binaries, and debugging > + programs linked against GLIBC 2.33 and earlier, but which are not > + linked against libpthread. > + > + ** The command 'set force-internal-tls-address-lookup on' may be > + used to force the internal TLS lookup mechanisms to be used. > + Otherwise, TLS lookup via libthread_db will still be preferred, > + when available. Do we support TLS on any platform but Linux? > +@kindex set force-internal-tls-address-lookup > +@kindex show force-internal-tls-address-lookup > +@cindex internal TLS lookup > +Turns on or off forced use of @value{GDBN}-internal TLS (Thread Local > +Storage) address lookup code. Use @code{on} to enable and @code{0} to > +disable. Please add here some index entry that uses "thread-local storage". Also, "TLS" should be in @acronym (here and elsewhere in the patch). > +When disabled, @value{GDBN} will attempt to use a helper > +@code{libthread_db} library if possible, but will fall back to use of > +its own internal TLS address lookup mechanisms if necessary. > + > +When enabled, @value{GDBN} will only use the @value{GDBN}'s internal > +TLS address lookup mechanisms, if they exist. > + > +This command is only available on targets for which internal TLS > +address lookup support exists. I think we should tell here that this setting has effect only for targets that use libthread_db.