From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JwWnDxZjCGdGHwkAWB0awg (envelope-from ) for ; Thu, 10 Oct 2024 19:28:22 -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=eFywwBFP; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 294891E357; Thu, 10 Oct 2024 19:28:22 -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 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 2631C1E05C for ; Thu, 10 Oct 2024 19:28:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 988063857003 for ; Thu, 10 Oct 2024 23:28:20 +0000 (GMT) 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 7C3B9385840A for ; Thu, 10 Oct 2024 23:27:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7C3B9385840A 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 7C3B9385840A 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=1728602880; cv=none; b=xIi47qfZcDFB+RYBeetnevJchMusYxyusO2WRVHkHcIYmqk4glphRPAVWRQ73mQCfsAM/+WFoZg0TuXg/MfqZrQeTx1vl+aApLgnnvO3h12C/Film3jv/mhDXNGjqD5uZKY0qem4MrJ2HGlvClauCuF3DO2HXy28xkElhF5Y5u4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728602880; c=relaxed/simple; bh=W2dXY5tTfXYT8K757DVitYqaVD8gdXm7ihmTftdzSIM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=IhMwjNTOJ8I6TqdUhvT4M4j3tz4TZfe5Vhjbb25zluL87B347QwU3W21MDWLzobsDqc/E7peTrS5c6pWUXfnIsxYg1ODscnOEtWMLb5MNhPIxctBbkN9PfSqR+y/3dc4TwQ1fFtMIjBs0YJrBVA1mC5cZN5h+wm/KGBYQeb6sFU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728602878; 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: in-reply-to:in-reply-to:references:references; bh=yDZO+nE27MMGSJK6w2LX94HVQzLZ3bntEcn90VRPYrE=; b=eFywwBFPW7/jIMUN0N3OvJH4D93n4IfamQeeUyuFFuQITh1bTaqCk/zFHBauNQSggkldZs B8Asq+UyArqgMbEv/2PfqOF2xMXmPNbq+VIL01dxTP+mLy8k/NM7gExYdVAg3gX4lNpgAE KBBU7sOiHoCVgoCa8w2A93gIlJrgRrk= Received: from mx-prod-mc-05.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-617-_E499VNJOv6AhCPv3_omHg-1; Thu, 10 Oct 2024 19:27:57 -0400 X-MC-Unique: _E499VNJOv6AhCPv3_omHg-1 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 06AFB195608A; Thu, 10 Oct 2024 23:27:56 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.64.14]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 29C581956089; Thu, 10 Oct 2024 23:27:54 +0000 (UTC) Date: Thu, 10 Oct 2024 16:27:50 -0700 From: Kevin Buettner To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 11/11] Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command Message-ID: <20241010162631.6fe74f4b@f40-zbm-amd> In-Reply-To: <86iku0339g.fsf@gnu.org> References: <20241010022552.47637-1-kevinb@redhat.com> <20241010022552.47637-12-kevinb@redhat.com> <86iku0339g.fsf@gnu.org> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 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 Hi Eli, On Thu, 10 Oct 2024 09:01:31 +0300 Eli Zaretskii wrote: > 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. I'm trying to figure out where in the doc to add background material regarding TLS. Adding it to the text explaining the new command doesn't really fit with the way that other commands are documented. It seems to me that it ought to be placed in some prefatory remarks. If so, should it stay within "Debugging Programs with Multiple Threads"? Or would it make sense to make a new section, perhaps named "Thread Local Storage"? Without getting bogged down with texinfo markup yet, here is what I propose saying about TLS: For some debugging targets, GDB has support for accessing variables that reside in Thread Local Storage (TLS). TLS variables are similar to global variables, except that each thread has its own copy of the variable. While often used in multi-threaded programs, TLS variables can also be used in programs without threads. The C library variable 'errno' is, perhaps, the most prominent example of a TLS variable that is frequently used in non-threaded programs. For targets where GDB does not have good TLS support, printing the value of errno might not be directly possible. Linux and FreeBSD targets have support for printing TLS variables. On Linux, the helper library, libthread_db, is used to help resolve the addresses of TLS variables. Some FreeBSD and some Linux targets also have GDB-internal TLS resolution code. Linux targets will attempt to use the TLS address lookup functionality provided by libthread_db, but will fall back to using its internal TLS support when libthread_db is not available. This can happen in cross-debugging scenarios or when debugging programs that are linked in such a way that libthread_db support is unavailable - this includes statically linked programs, GLIBC versions earlier than 2.34, and use of other (non-GLIBC) C libraries. [Doc regarding "set force-internal-tls-address-lookup" goes here.] There's a lot more that could be said about errno. Earlier this year, I wrote an article about it. See: https://developers.redhat.com/articles/2024/06/05/why-your-errno-value-isnt-printing-gdb-and-what-do-about-it That article dealt with errno problems on Linux, but some of the same tricks, with some tweaks, might apply to other environments too. It might make sense to try document some ways to obtain the value of errno when "print errno" doesn't just work. But that can be the topic of another patch. With regard to the question of why you might want to force use of internal TLS lookup, it's mostly for testing purposes. For the new tests that I wrote, I needed a way to ensure that the internal TLS address resolution code was being used, so I made a command which does that. I'll mention that in a v2 patch. I do, however, already mention it in the help text: (gdb) help set force-internal-tls-address-lookup Set to force internal TLS address lookup. When resolving addresses for TLS (Thread Local Storage) variables, GDB will attempt to use facilities provided by the thread library (i.e. libthread_db). If those facilities aren't available, GDB will fall back to using some internal (to GDB), but possibly less accurate mechanisms to resolve the addresses for TLS variables. When this flag is set, GDB will force use of the fall-back TLS resolution mechanisms. This flag is used by some GDB tests to ensure that the internal fallback code is exercised and working as expected. The default is to not force the internal fall-back mechanisms to be used. Kevin