From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BkY6JgiHu2ooyhYAWB0awg (envelope-from ) for ; Tue, 29 Sep 2026 05:38:16 -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=ihY12Xpq; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 782851E033; Tue, 29 Sep 2026 05:38:16 -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 vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 4E6D81E033 for ; Tue, 29 Sep 2026 05:38:15 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A8C7B4BB24D9 for ; Tue, 29 Sep 2026 09:38:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A8C7B4BB24D9 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=ihY12Xpq 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 851494BA543C for ; Tue, 29 Sep 2026 09:37:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 851494BA543C Authentication-Results: sourceware.org; dmarc=pass (p=quarantine 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 851494BA543C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790674664; cv=none; b=taffJEiJiBKQNlwb7Q1vAkNWHfbViThNl5SvdVmH7TgvP2hMb+VAosAYZ78murmSpxDda6S39H5OLr2NMugSGvylPeAeO+EvbGWn/mXLe7EEGR+/chigZErgfp89cRiRsKmpPRwf1iS/F6ejAsItoAFhbr4I5a4tIhRdVEQKMb0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790674664; c=relaxed/simple; bh=9E0a/9aa6PMEYRQ2dbNzH9x9oFK8IaCv1ipK23/GS0s=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=VPL7Ve9EHOef0BcxjxXG+NQEtqWHaMfbWeJcHqFZAqb7lFEU3O1lbt3j94qsDCO4avO7VCM5ZJfwVYuCWCuPNynwxtEFdst/c9zdis+s8C6zohhO/GB/t7Mde9ukER9ogVz2Qmv26dZWgwYERBnSGJCi0HSz6w8cCuNQ736XFKA= ARC-Authentication-Results: i=1; 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=ihY12Xpq DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 851494BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790674663; 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: in-reply-to:in-reply-to:references:references; bh=nE2YrkNvicplt0Iyjz0Dattx5PGtYTpaUKjEgvB5jGA=; b=ihY12XpqObh8Phc/TNpRPnZtCT7WcpO3LgzHEcFvRkK2a+iSthfflmjPzBpy9t8pmFjKMR jw6Y+tD0f+eMj1fRAo6Xu41l28BmqhxsGstpp0QQ5nRFCL+syIY8P1e13SDMpaaHTQzeg6 5Lm54JJ2Nx0hyMnBAGMSx3akxcnbiyk= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-111-dGPdfAfeP8O_jkU1vFJ81A-1; Tue, 29 Sep 2026 05:37:40 -0400 X-MC-Unique: dGPdfAfeP8O_jkU1vFJ81A-1 X-Mimecast-MFC-AGG-ID: dGPdfAfeP8O_jkU1vFJ81A_1790674659 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-49fffa5de0fso35334255e9.1 for ; Tue, 29 Sep 2026 02:37:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790674659; x=1791279459; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=nE2YrkNvicplt0Iyjz0Dattx5PGtYTpaUKjEgvB5jGA=; b=0C80dN+QguwZqpG/AbCRmPH1bIp8x5i+nuMPwnBSyOL3mOUkMqGEFBtsilw90tvltI I9Vdw/JYVvv3sLOGzaWEaX6SiHIQAROlO8tw3xHZ6Rkhv5JCGVuxLU3auPIbQ0DhOvTg SzknJmThvS4FfqUj689n5dsbMXtsXC3am9sRNPcD9K2nP1U9yrGBdNAn1Zlm1oDCHeAV vSLV+8R7xHewp49WpLfcFrE5FuQsUF5WSdgpwIoGkySNq8anak7/XNVbXtHX6tqLpCS3 KdYxQpiRBR+idSrVnWd/mKubj5hMGJJE8D/BhefTBPrCP8o8bAD/oUP4iEcNc0yJk8sL x4EQ== X-Forwarded-Encrypted: i=1; AKwUvByUzGkIGvnZiPJzrgO9ZoJ1Il33TkBAP9hrAOgKsQZWb98IL3XVSHUlMaHa3YbRFB/R59KReUrhCTrxqg==@sourceware.org X-Gm-Message-State: AFuF++mvsR1QVi50syVvxH4c7DTON5wRmXq8wU1gvgnfCLnGbtgMXF1P 73wuZNbc9EPCbL5TwooCZ8zUe623N1U/Ucq4Je5Jf3ghpTy470MCVWIhMKKsa6ifivkSSD4FMNa o7j/x/u2K6CBtl+bqOjXtwpHjQlLje1T46R9BGfl1BuR414sOCi2tEE5iawjikmBk6qGwhs4= X-Gm-Gg: AYBFou2xxYDyAEOA7164BJlcxILCwEvKaJo32y/OjjMhWa1kMtMMlFiNAEorlHfwe5P tEftANMbKi3La0Bugb7cP7FKqhjplF5x9gkBW3tO4nhdpKSmtGxCQ8sIlqa2TS3FbBf7aTgdlCg tHiPULWBjYVHlVwXt71pmEqXE4tP3VaujnN8h1Bo/Dn9NXi24GKKiqqZ2idqlVjocvlvSTytLyA Mu8dGFHRb5Z3VNQnUuc0HRf1rtF80TKT/0dK2t9Wpj7OyTBBCER+HgbScbXsQ2Ap5A5Xod2rjhH Lt2vKSEdPllobv99YIPZydh7t9I7hM2k6nW680bAOb3AORAzhpYbNKA3KLReD5zE6Cg/Yg== X-Received: by 2002:a05:600c:4f44:b0:4a0:23f:8b0d with SMTP id 5b1f17b1804b1-4a0023f8d93mr125746135e9.2.1790674658839; Tue, 29 Sep 2026 02:37:38 -0700 (PDT) X-Received: by 2002:a05:600c:4f44:b0:4a0:23f:8b0d with SMTP id 5b1f17b1804b1-4a0023f8d93mr125745785e9.2.1790674658368; Tue, 29 Sep 2026 02:37:38 -0700 (PDT) Received: from localhost ([213.31.44.29]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a00cf8f93csm69174875e9.5.2026.09.29.02.37.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Sep 2026 02:37:37 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , gdb-patches@sourceware.org Cc: Simon Marchi Subject: Re: [PATCH] gdb: use NT_386_TLS regset to access TLS GDT entries on i386 Linux In-Reply-To: <20260928172119.425553-1-simon.marchi@efficios.com> References: <20260928172119.425553-1-simon.marchi@efficios.com> Date: Tue, 29 Sep 2026 10:37:36 +0100 Message-ID: <87zex0z9cv.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 9AaGAq45ooF7pILvd7O6euPOIhqNLwRyDSr-9KW-WXA_1790674659 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Simon Marchi writes: > Bug 34678 reports that a 32-bit GDB running on an x86-64 kernel can't > make inferior function calls: > > (gdb) p f() > Couldn't get TLS area data: Invalid argument. > > This happens because GDB fails to read the special registers holding the > TLS GDT entries, added in commit 91eee81d2353 ("gdb: include NT_I386_TLS > note in generated core files", 2025-11-20). > > The failure isn't specifically related to inferior function calls, but > it is most visible there when GDB attempts to save all registers prior > to a function call. > > These "registers" are read using > > ptrace (PTRACE_GET_THREAD_AREA, pid, addr, data) > > where `addr` is not an address, but the index of a GDT entry to read. > The valid indices depend on the arch of the kernel. For an i386 kernel, > the valid range is [6, 8], while for an x86-64 kernel, the valid range > is [12, 14]. > > As commit 91eee81d2353 properly noted, the indices really depend on the > kernel, not on how GDB or the inferior program were built. On an x86-64 > kernel, even when GDB and/or the inferior are 32-bit programs, we need > to query the x86-64 indices: > > /* This constant defines the first GDT (Global Descriptor Table) entry > that the kernel allocates for holding TLS descriptors. There are three > entries, starting at this index which can be accessed using the > PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA ptrace calls. This > constant is only valid for true i386 kernels. For amd64 kernels > running in 32-bit mode (i.e. executables compiled -m32) there is a > different constant, see nat/amd64-linux.h. */ > > However, the implementation isn't quite right, since it bases the > decision on whether GDB itself is a 32-bit or 64-bit program. So we get > it wrong when GDB is a 32-bit program, debugging a 32-bit program, on a > 64-bit kernel. GDB queries the i386 indices, which gets an EINVAL > reply, because it should have used the x86-64 indices. > > Also, according to Claude (I couldn't test since I don't have a machine > with x32 userland), PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA > are not supported for x32 tracers: the kernel's x32_arch_ptrace doesn't > handle them, so they would fail with EIO. An x32 GDB debugging an i386 > program therefore couldn't read the TLS registers either. > > Fix both problems by using the NT_386_TLS regset instead, with > PTRACE_GETREGSET and PTRACE_SETREGSET. This regset contains the three > TLS GDT entries, so accessing it doesn't require knowing their indices. > When reading, the kernel fills the entry_number field of each entry with > the right index. When writing, it ignores the entry_number fields. > This is the same data as the NT_386_TLS core file note, which these > registers are used to produce. > > This also makes it possible to read the three entries with a single > ptrace call, instead of three. > > Remove the i386_initial_tls_gdt constants, which are now unused, along > with nat/amd64-linux.h, which only contained one of them. > > Tested by running gdb.arch/i386-tls-regs.exp on all these > configurations: > > - x86-64 kernel, 64-bit GDB, native > - x86-64 kernel, 64-bit GDB, gdbserver > - x86-64 kernel, 32-bit GDB, native > - x86-64 kernel, 32-bit GDB, gdbserver > - i386 kernel, 32-bit GDB, native > - i386 kernel, 32-bit GDB, gdbserver > > This test would previously fail in the "x86-64 kernel, 32-bit GDB" > configs. > > This is a regression in GDB 18, so this patch would need to be > cherry-picked to the gdb-18-branch. Thanks for fixing this, and for the well written commit message. Just today someone emailed me off-list reporting this problem: https://inbox.sourceware.org/binutils/CAG_eJLe_vuR93fE6H4hENPh3=R2XE72T2tL1ZaTnY93zW2J5-Q@mail.gmail.com which did make it to the gdb-help list via a CC on a follow up post, but unfortunately never made it into a release blocking bug. The issue here is that PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA don't exist for older glibc, they were added in glibc 2.27 I believe, which is after the glibc 2.23 the bug was reported against. The NT_386_TLS that this patch uses instead was added in glibc 2.10, so this patch should fix that build issue problem on older glibc too. For both master and gdb-18-branch: Approved-By: Andrew Burgess Thanks, Andrew