From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Xv70AvK6CGc0dQkAWB0awg (envelope-from ) for ; Fri, 11 Oct 2024 01:43:14 -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=fRENRB5H; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E00621E357; Fri, 11 Oct 2024 01:43:13 -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_BLOCKED,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 C67C61E0C0 for ; Fri, 11 Oct 2024 01:43:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 393EB385772C for ; Fri, 11 Oct 2024 05:43:03 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id C0F8A3858D26 for ; Fri, 11 Oct 2024 05:42:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C0F8A3858D26 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 C0F8A3858D26 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=1728625360; cv=none; b=Desf4CWu8h2tJxZ1ar1wbDzJQqZIR2Y8MXVXFgtrgD6PQ4ZowxKCDcYLfx15I7krXRLsA4o3A3Z/HATyuQvzS4TjzBFG16JLkziBqQPJirbfNtOhxm7EBKYs+ULK3hIAoZ9v0AY1wRtjggH4Mmt17XW0pVRJNNG0gckubAcHej0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728625360; c=relaxed/simple; bh=xQvUxihbNSqsAQ/mC9Bf6iBTa6tNeL6k+S6+3silM/Y=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=DzWo6lGloNRemZ5wC8aFQPA777ZD/JTyrI+AzXJG1XTciwyUAgMVxK3u/qhaA+7Y7BN1UDA2acNEjHMwSdMFhdab2t2S0b01wNZiN4vAxXnMz291Ftpl1eZS+9gPX/AmLcldt+THtF+Sv7MpE+ZyUAr751F7J7P+e6J3/cLqtEg= 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 1sz8Q8-0001h8-8y; Fri, 11 Oct 2024 01:42:37 -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=2/1nmDJR7Ct/zfJCxUoeU28xLxdrbcmYK+HYvx3tPao=; b=fRENRB5H5OOw HIiuL+KXOggwN1DOin9dC8AtHVfv7kptPySeUuD+IqmHvqKDf0SBU/uY2qzzErkZAH50qdObfJB+j jvlqyI1rdHGS8TSoqfGLnELx/b6Mp0zZfNHSFdJ380z1fb1FHynbdbDnqWOTzC4A+4PFHwLkOwgHC ypep9uXKplzF3971j6f76jP7ysZ1WRzPbqdae6A5XmDAGUSifnRnV83YN+fJDdDfAGjlJj5PH3pb3 HWo3B41FaoAawHH/eEbMhG3TxqNaBGave95Wpn2tFm1tyu2cIb0XRdX3nRM3V8l8VmgBGWbMtF4a9 a2a+En8vJ8PgVeZOENsSGA==; Date: Fri, 11 Oct 2024 08:42:33 +0300 Message-Id: <8634l319h2.fsf@gnu.org> From: Eli Zaretskii To: Kevin Buettner Cc: gdb-patches@sourceware.org In-Reply-To: <20241010162631.6fe74f4b@f40-zbm-amd> (message from Kevin Buettner on Thu, 10 Oct 2024 16:27:50 -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> <86iku0339g.fsf@gnu.org> <20241010162631.6fe74f4b@f40-zbm-amd> 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 > Date: Thu, 10 Oct 2024 16:27:50 -0700 > From: Kevin Buettner > Cc: gdb-patches@sourceware.org > > 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"? We could leave it in the multiple-threads section (as the text is not too long, and is related to threads), or we could add a new section under "Data". In the latter case, you'd need to use cross-references judiciously, both in the new section and in "Threads", to provide the reader with all the relevant information, since libthread_db and the commands related to it are only discussed in "Threads", and the new command will be described there as well. > 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. LGTM. > 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. We can have a summary of that in this new section. Btw, the MS-Windows situation is similar to what you describe for Linux. The MinGW says: _CRTIMP int *__cdecl _errno(void); #define errno (*_errno()) So one can display errno by calling this function with an explicit type-cast. Maybe we should mention that if and when we add this to the GDB manual. > With regard to the question of why you might want to force use of > internal TLS lookup, it's mostly for testing purposes. If this is for testing, shouldn't it be a maint command?