From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cm9PDHBa7mgupTEAWB0awg (envelope-from ) for ; Tue, 14 Oct 2025 10:13:04 -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=sOAzhxo0; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1DF1C1E0B6; Tue, 14 Oct 2025 10:13:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED 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 E569B1E047 for ; Tue, 14 Oct 2025 10:13:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 663043858420 for ; Tue, 14 Oct 2025 14:13:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 663043858420 Authentication-Results: sourceware.org; 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=sOAzhxo0 Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 233073858D38 for ; Tue, 14 Oct 2025 14:12:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 233073858D38 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 233073858D38 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=1760451147; cv=none; b=F5oqPA4+j59Xy8Es8kS5n9TiQ1i2z9MmHtp6Pqr6DIocxWlj+LcWaiYyDR+QXhyMWjLGhFsXV4m+q9DZuYcOre2NVKBNZ4+0LeA/P+EsHbC8p7sU0v207kMOrXxn5RP73qOMiu8+5kZlMZVbnbzneuxjhONsDvTn0kvtPI1wp20= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760451147; c=relaxed/simple; bh=5kYjKqBPczQX8ers1P00TUibAFVq7bcJXj7NrVW4Xyc=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=Z9aieNdVSFSA+tTpynI5MSf4tgkMqih3MamwZZMnc8qCkZhNIkqVXDl1RKYjsmBHwCXMLMe8wgJ//dK9f+AO4omgDZFuEd884zmBN+xC5+qu4CvRYIut7UzLM4rkWjKhQKpqDagq3JuiBz89QCe05vrtQEbHVi6waye9AVUl3nA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 233073858D38 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 1v8flK-0005ZN-3L; Tue, 14 Oct 2025 10:12:26 -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=YtnmLVd6vn1s/YvD7iKFB/VhX+f2XnT6v4Ec6emyt/k=; b=sOAzhxo00Brp 51GQy0X1uZln54o0YMlfqNhmvibFafXHBbVHXvTOgeRI5331G9AvDYeTEzpEN6FxJY62El13F8AJb 69j9KGamIiVYnDTyEJ+4AVsplxZOSYAPKJ5MQhVQssQqLNULFKBJIYNQ1PhuRXRQNlILHZNvCJkQH EACrfLWA1gVAXBXy36G36qMcjHOWkAG386ko6dpMGXAfRIXqU8GUwcLNfuM4d5Wds2Y23hhW/jno5 QkXsWE0vGyhyBKaMzeNgR8DJOvW68hdJT40EGyLTExXanY/UOQOrQlocy3gTbWE+For6YvWuJGtgh nhu+mELp+dG9Ovsnn6FKsA==; Date: Tue, 14 Oct 2025 17:12:19 +0300 Message-Id: <86cy6p373w.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: <730728a6858a3fcf4477ebe3895088c98f0fead2.1760450001.git.aburgess@redhat.com> (message from Andrew Burgess on Tue, 14 Oct 2025 14:54:28 +0100) Subject: Re: [PATCHv3] gdb: include NT_I386_TLS note in generated core files References: <730728a6858a3fcf4477ebe3895088c98f0fead2.1760450001.git.aburgess@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: Andrew Burgess > Cc: Andrew Burgess , > Eli Zaretskii > Date: Tue, 14 Oct 2025 14:54:28 +0100 > > In v3: > > - Fixed doc issue that Eli pointed out. > > - Rebased to current HEAD, no merged conflicts. > > In v2: > > - Rebased to current HEAD, resolved merge conflicts related to > recent i386 register changes. > > - Updated test to take account of recent clean_restart changes. > > - Retested. > > --- > > This commit extends GDB for x86/Linux to include the NT_I386_TLS note > in generated core files (i.e. created with `generate-core-file` or > `gcore` command). This note contains the 3 per-thread TLS related > GDT (global descriptor table) entries, and is present for i386 > binaries, or those compiled on x86-64 with -m32. > > The approach I have taken to achieve this, is to make the 3 GDT > entries available within 3 new registers. I added these registers to > the org.gnu.gdb.i386.linux target description feature, as this feature > seemed perfectly named. As the new registers are optional I don't see > any harm in extending this existing feature. I did consider adding a > new feature with `tls` in the name, but this seemed excessive given > the existing feature. > > Which GDT entries are used for TLS varies between i386 and x86-64 > running in 32-bit mode. As such the registers are named with suffixes > 0, 1, and 2, and it is left to GDB or gdbserver, to find the correct > GDT entries (based on the precise target) and place the contents into > these registers. > > With this done, adding the relevant regset is sufficient to get the > tls contents emitted as a core file note. Support for emitting the > note into the generated core file relies on some BFD changes which > were made in an earlier commit: > > commit ea6ec00ff4520895735e4913cb90c933c7296f04 > Date: Fri Jul 25 19:51:58 2025 +0100 > > bfd: support for NT_386_TLS notes > > The three new registers are readable and writable. Writing to one of > the new registers will update the relevant kernel GDT entry. > > Each TLS GDT is represented by a 'struct user_desc' (see 'man 2 > get_thread_area' for details), the first 4 bytes of each 'user_desc' > is the 'entry_number' field, this is the index of the GDT within the > kernel, and cannot be modified. Attempts to write to this region of > the register will be ignored, but will not give an error. > > I did consider not including this part of the user_desc within the > register value, but this becomes difficult when we consider remote > targets, GDB would then need to figure out what these indexes were so > that the core file note could be generated. Sure, we probably could > figure the correct index values out, but I figure, why bother, we can > just pass them through in the register and know for certain that we > have the correct values. > > For testing, there's a new test that covers the basic functionality, > including read/write access to the new registers, and checking that > the NT_386_TLS note is added to the core file, and that the note > contents can be read by GDB. > > I also manually tested opening a core file generated from an old > GDB (so no NT_386_TLS notes) using a GDB with this patch. This works > fine, the new tls registers are not created as the NT_GDB_TDESC > note (the target description) doesn't include the new registers. > > Out of interest I also patched an old version of GDB to avoid creating > the NT_GDB_TDESC, and created a core file. This core file contained > neither the NT_386_TLS nor NT_GDB_TDESC. When opening this core file > with a patched GDB, the new registers do show up, but their contents > are given as , which is exactly what we'd expect, GDB > builds a target description based on the architecture, the > architecture says these registers should exist, but they are missing > from the core file, hence, . > > I also tested using a patched GDB with an old version of gdbserver, > the new registers don't show up as the old gdbserver doesn't send them > in its target description. And a core file created using the gcore > command in such a setup leaves no NT_386_TLS notes added, which is > what we'd expect. > > And I also tested a new gdbserver running with an old version of GDB. > As the new tls registers are now mentioned in the target description, > then obviously, the old GDB does see the registers, and present them > to the user, however GDB doesn't know how to use these registers to > create a NT_386_TLS, so that note isn't added to any core files. > Also, while a new GDB places the tls registers into the 'system' > group, an old GDB doesn't do this, so the registers end up in the > 'general' group by default. This means they show up within 'info > registers' output. This isn't ideal, but there's not much that can be > done about this. > > Overall, I feel the combinations of old and new tools has been tested, > and the behaviours are what we'd want or expect. > > I'm tagging this commit with PR gdb/15591, even though this patch > isn't directly related. That bug is for improving GDB's testing of > TLS support in core files. The test in this commit does do some very > simple reading of a TLS variable, but there's only two threads, and > one TLS variable, so it's not extensive. Additionally, the test in > this commit is x86 only, so this should not be considered a full > resolution to that bug. But still, it's something. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15591 > > Reviewed-By: Eli Zaretskii > --- > gdb/NEWS | 4 + > gdb/amd64-linux-nat.c | 26 +- > gdb/doc/gdb.texinfo | 11 +- > gdb/features/i386/32bit-linux.c | 7 + > gdb/features/i386/32bit-linux.xml | 5 + > gdb/i386-linux-nat.c | 21 ++ > gdb/i386-linux-tdep.c | 171 +++++++++- > gdb/i386-linux-tdep.h | 15 + > gdb/i386-tdep.h | 5 + > gdb/nat/amd64-linux.h | 29 ++ > gdb/nat/i386-linux.h | 10 + > gdb/nat/x86-linux.c | 44 +++ > gdb/nat/x86-linux.h | 15 + > gdb/testsuite/gdb.arch/i386-linux-tls-regs.c | 74 +++++ > .../gdb.arch/i386-linux-tls-regs.exp | 314 ++++++++++++++++++ > gdb/x86-linux-nat.c | 67 ++++ > gdb/x86-linux-nat.h | 17 + > gdbserver/linux-x86-low.cc | 99 ++++++ > 18 files changed, 928 insertions(+), 6 deletions(-) > create mode 100644 gdb/nat/amd64-linux.h > create mode 100644 gdb/testsuite/gdb.arch/i386-linux-tls-regs.c > create mode 100644 gdb/testsuite/gdb.arch/i386-linux-tls-regs.exp Thanks, the documentation parts are okay. Reviewed-By: Eli Zaretskii