From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SYJYHifevGqWrR0AWB0awg (envelope-from ) for ; Wed, 30 Sep 2026 06:02:15 -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=ewWnEDsh; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7919C1E033; Wed, 30 Sep 2026 06:02:15 -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.1 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_SBL_CSS autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 6E44B1E033 for ; Wed, 30 Sep 2026 06:02:14 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 112154BB3BAB for ; Wed, 30 Sep 2026 10:02:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 112154BB3BAB 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=ewWnEDsh Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 982274BA23D0 for ; Wed, 30 Sep 2026 10:01:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 982274BA23D0 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 982274BA23D0 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790762502; cv=none; b=u3sUsJWj+f+zx4vpGUkIX2fpn8Jivqtf1PQzZ4WNKQYsdR8RlbvP3ylzHFaqOnK7S05PbdSdlErIDImscqNiaDDH1x3OpqVcmv3nJZ+h2SgrdLDkIpsnscEY9hDtTTZ9AAs3ySHlq8RtmYbn9fz9uJCgsHH9pJ9mqHfHOOkL3KI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790762502; c=relaxed/simple; bh=UBMMmdGJrypPG58ucx0oLKy5V2QgKp8FyBfZKAyfq6w=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=j45x7vE2wb+5m1tmVpvFkumrDjDwB0hxywPslRY/V5XzE2nsXSIIXkq5dpGF+/+RMGTQaD2mJdkv2QPQJogn0BM14OIEwm94JShhj5CEcSPLgpPFp6YVC6ECQaRauf3NYc/a68NMuQYiUSP/mFKOmJb5UhfYV2z74T/eNlelXRw= 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=ewWnEDsh DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 982274BA23D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790762500; 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=+dWFmJrYOLGh0Obn4hEpvNkwjm5Hbn1SPBJ5mCcxDQE=; b=ewWnEDshiR35WnBWWB55v8u/6Kh28ohs4lawDEE1d7Z/i7dXzPZjYsVeWhdpYARnD0zUxk aoL1v1ERcbRhYIyBuaHRM2r6YNR1dild9ZpQ9tI6rS6UPpIk487tC0wggp36yC3npg9gdZ zTvRHfqMGEit44glOeapLRYAlOIyTgw= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-652-703nP88BOSWG9t6kFHtEKg-1; Wed, 30 Sep 2026 06:01:37 -0400 X-MC-Unique: 703nP88BOSWG9t6kFHtEKg-1 X-Mimecast-MFC-AGG-ID: 703nP88BOSWG9t6kFHtEKg_1790762496 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-48af4046a3bso1757593f8f.2 for ; Wed, 30 Sep 2026 03:01:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790762496; x=1791367296; 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=+dWFmJrYOLGh0Obn4hEpvNkwjm5Hbn1SPBJ5mCcxDQE=; b=NbdwW2KbI0LWzOCtCQ9Pp4697b3GvVEv/l+ZblyyR22EMhl121zEh1d5tUg2or6S+l NoS55V6og3B4tlLtspo/G4ERjW4e2XP5P7ojbJhwh7rgeEhpseKqISgb8DcQkNUfeiZB mGEb1WAkBKnDdInlOObU8R7hjO2Q3LNExFiG10FNJfpvqGFdJoCKp5Tn7Y2wpFF/QoHJ SN4wgIKbAAKXhBxizxx50pgB7PE0yECfZ6186h7BNSs9NI5gnG5QgtW3ilbYe/63u8Az C8aiMfMkrUK02SxA0yW+XlMFUToVBrJrYfY1h5kt4kDrus6KM820rb1wdbxOH58MI12l wQGg== X-Forwarded-Encrypted: i=1; AKwUvBywRHHO2UEppLM87t8Wjk/FUrrme+g7pk3jM5FggZ4LKQTi3c2VoUJEPmIvca3KZVdqLwmb0/zh+yBk8A==@sourceware.org X-Gm-Message-State: AFq9FYLs9NW4lEcCc9jJtY7eFgryiqzDegihfzEuIoVRMmTU6jsw1QqT yHknAaT/eg7eKaCsscDYMx63N2I+WSuZt8ZOzkrk8RFWtE3AbpJeePUGV0ILa0beaTp/8g8jC7u 4cjzTImLzQagDgQ+PQN3FiMCNS7nGHbkmEE/gVV5fWo//ADvcq1AuGOn+l1BSd9Y= X-Gm-Gg: AYBFou0PBDO7iABj2Lin4X/W6Lt9AeOnhMeaGzFHsa1Fn6Ei6SfZApIJ8oQfSXYltks HG07V/GKlxD0U4DPM1J+FCEEVLVuzBaWGB835UIVZvzNUQd1D4n2C0B7K3MvXZA7lKICUcgCt22 uZCiscNW3csG8yH/4sqGvO1NuUddnw5jXlem2opSTXButcw4fW8LW4fX2BhGfWCQQ5totjLCkyM XZwyxcztXc1ZihlLzJsLiPmXJvORVUzBhFNlTmFu3wJTbTMuH0zpGYrCeKdPxhbuPIvo9IjeRIi kU4sfu5wSNjHGjCPwuP8ND41+Exlb73XI56gzbXpC38aiPGP0Y+1JnnNnbqwnFVvf0e+XESALrO LP0XA3K53pWcTjKqpQ/RjuH5U X-Received: by 2002:a05:6000:60b:b0:487:f31:8037 with SMTP id ffacd0b85a97d-48b024ea79dmr1745316f8f.14.1790762495002; Wed, 30 Sep 2026 03:01:35 -0700 (PDT) X-Received: by 2002:a05:6000:60b:b0:487:f31:8037 with SMTP id ffacd0b85a97d-48b024ea79dmr1745107f8f.14.1790762493004; Wed, 30 Sep 2026 03:01:33 -0700 (PDT) Received: from localhost (92.40.185.180.threembb.co.uk. [92.40.185.180]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48b02a0c302sm2201311f8f.34.2026.09.30.03.01.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Sep 2026 03:01:32 -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: <87zex0z9cv.fsf@redhat.com> References: <20260928172119.425553-1-simon.marchi@efficios.com> <87zex0z9cv.fsf@redhat.com> Date: Wed, 30 Sep 2026 11:01:29 +0100 Message-ID: <87fqyrys5i.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: TkNhe1qfuucSe226-pzdJeq9cizu8_BN1HqvnFQi7kI_1790762496 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 Andrew Burgess writes: > 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. I had the reported try this patch and they have now confirmed that this patch does fix their building with and old glibc issue. They are happy to carry this as a local patch, so there's no urgency, but thought this was a good data point to record. Thanks, Andrew