From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZNpVDePJu2qz2BcAWB0awg (envelope-from ) for ; Tue, 29 Sep 2026 10:23:31 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=j0coMHJ3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1EB991E06B; Tue, 29 Sep 2026 10:23:31 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED 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 C2D981E01F for ; Tue, 29 Sep 2026 10:23:29 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EEB504BB3B8D for ; Tue, 29 Sep 2026 14:23:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EEB504BB3B8D Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=j0coMHJ3 Received: from YQZPR01CU011.outbound.protection.outlook.com (mail-canadaeastazon11020075.outbound.protection.outlook.com [52.101.191.75]) by sourceware.org (Postfix) with ESMTPS id 0B3434BB24F5 for ; Tue, 29 Sep 2026 14:22:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B3434BB24F5 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0B3434BB24F5 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=52.101.191.75 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1790691780; cv=pass; b=IAj51W+/4DN3OlzmejjPekKiXPkXRbpGQEyu+kC/2IE/5T3zUPM1jFE5WP+cl8dNEa5Q0FoKLp/QfSrb5kdJYSPFFqBGzooEXznkJP8Nw/JIoKevdHJsZbp2e1X43jkD4uRdoqKtualJ2XqIjXZxpk4FpvukxwrPvjrZ42K893o= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1790691780; c=relaxed/simple; bh=UCRpkmNeh7wYd7AfC/MPuKBx+aMKyFaI7NBnB7UZFQU=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=ETJ/g/HG5+FxTiBlKkgUKehwCXMj00UXnMPPE647OpkwhRjUB3+AAp1wFQu8MKksP4tGhnzLgz9AY6aUkeM9WOVKDhLWz57WqOOQ6/zVJ+KFcIz7s+RV2cdEAV/GkdzQediryKI1zSwnfbC6imCrcwpPlwQ1maOmbfuQxFLFH/0= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=j0coMHJ3 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B3434BB24F5 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ki7SZdHL4opwDAmW/PTfTeEIjuJb/ys5F1hK86h2MQA4qscnqkuMaz9tK0weYhMVGTkMZ6MuejkcNs46JH2FFS3sKiHYGlXFr1876qoU1AtwgN6JTqexIAbdwxS1Tq5XPoRUIlxxQV3lmni9vDufxhg4ZXCcz/kzOecg6H/fOeudZAr4vd1K8JBI/+533p3k4XZ7gRq4ytmul91JavDnswOCKiBNtZDCt6flGmfO6zNOOJYkf9Ii+LPW/Z7Upl3yB9aWh6qhOt9D25FwOWGrnR+UehA93C/HE0OKzuOIp8mayXsbo0iCF5v/ubpp3mMmNBS7tiAMh6sbWbggeDoafg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kOh+omnjz5E7D94+d5BxBEHPNKpMcPBZ1Skmpi3UHZ4=; b=oRbqmzRE6/caj8mDB62vXj/vk24c/eg3wSAZSz9t1SzWAL1w3os6LgCH+mZio5rvpn86LpfPDig/wxETp+Avb6yWZSE/3jMQtwraFAMGddweOO8C/KDFFD3h/VEw+zoJZvksZ6haXIR5h0HjF6SxDJGHSGbsVtxwJ258nL9FFGNzIQ6ZET94JNgzjfZLY8r9oWeZj3Vjo04X9Z3thGZPYNYBsxbYvx8rwP9sEU4Vf7ZMDMm0r3Kt5IDy38SxgsUgfA5DiNNtMsmxKLjRaaGLyK3LvXT6iBUNvOFHcG1lDoHjtuCRx/mdOFNb4Lh1BUDb1OvYcy4ixSVFpcQLpQpKKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kOh+omnjz5E7D94+d5BxBEHPNKpMcPBZ1Skmpi3UHZ4=; b=j0coMHJ3h0ihMgWr3ycN2OJtQxgHh9wh/nmz2gJCfc5fe0l0yhUOVWaUsvl7oMWnCgvC55Vf/WNAdGOXJUMILMpQfs/Scp8shmsp+u2Lzvv+78CSt3Ao7+cTI+AjLMAphMyX/B0UZ+mR7ecXdaJeuy7tWkgakkFudCReGSagCDs4QkUNPrWFGHYo2/noKPw/i+t+oTfsZq8FUU9l1DbKV6rJ9NF+okZn9Jwu2ZmYq0nYqbjZ7jdCJOd9YYd3JVRJ9IrrHH29gg/UdiZn5tmXM7E0ASRkwDJEcIMAFMi4C5Vxq12SDvmP26EI68vwK73Q/0l93AY9dAtKV+WoEqSh6A== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2c::6) by YQ1PR01MB686067.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:d4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.26; Tue, 29 Sep 2026 14:22:52 +0000 Received: from YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM ([fe80::bbfa:179f:fdc8:b15d]) by YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM ([fe80::bbfa:179f:fdc8:b15d%7]) with mapi id 15.21.0451.026; Tue, 29 Sep 2026 14:22:52 +0000 Message-ID: <58661885-356d-460c-a2f0-d8ad23cd0452@efficios.com> Date: Tue, 29 Sep 2026 10:22:51 -0400 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: use NT_386_TLS regset to access TLS GDT entries on i386 Linux To: "Joos, Christina" , Andrew Burgess , "gdb-patches@sourceware.org" References: <20260928172119.425553-1-simon.marchi@efficios.com> <87zex0z9cv.fsf@redhat.com> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YQBPR0101CA0297.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:6d::16) To YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2c::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YQXPR01MB5418:EE_|YQ1PR01MB686067:EE_ X-MS-Office365-Filtering-Correlation-Id: 61ba6682-7d2b-45f9-aaa2-08df1e352587 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|376014|366016|10070799003|23010399003|1800799024|10067099003|56012099006|4143699003|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: CZVxRvikk75C85YwLwg6mZGah8bU4qVt+wqS44/UpJkiM6QskE7UK1iFBmT8QnWu/UTfgNvQjqrPAOm8pkHF+/1jvd1tmvruzi/TxwVDM4xox3bQfbtPNgjSr/ewbe00upMpDJ62qC2fX5nB0HlAWtxoMzcUUagw/Cd1t5TtCdMRMnVTWY984ROJ5/ws7q0YYsSYFMRXpvT9SZMY6Zm8GxynCtH4vmSXgeNPGioQWAQzRyW+3pFCa+qDUD6k8J6hm4Gdvxn6JKl/6wfo3oKwQfJz4EbsWA1xWr8RePxJ5VWNwV4Ebku1SOs0u/InAmtTEuL4fF3DJzduxHPL+zODfBIAzRkUQSaGzGlB3zOmGD/tAsuL8jXDXP5jqz+2WlaSZxMqQdIrgnukISME4kdYzlRYmKSSg22h/avYoG4+sUeevH+kf5LNc2OcI9bMGUhm99D78sb9dBb2CgPAtkwZ6SMnq1PkJazYHW73ZxKDN6YAx9bf3GaK4uVtXBaUF4/rmQx4p42qR7jUpylOsp8PLbBo4QBoGZEYSouqZkIIBe0ja1yq2oRsD/9A8cZWHR11Go3VqR97URgwkCta4qqwbKGZH1emvCWCyp4wnF0bmtSNlF2EuyhHGN5E6xfV7LOk X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230040)(376014)(366016)(10070799003)(23010399003)(1800799024)(10067099003)(56012099006)(4143699003)(6133799003)(22082099003)(18002099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Yy9mMlJma1NvSXJJTjBRaVYwRmc0SXlhYTMzQXVzWUVpY1FlRmxKVXMzMExj?= =?utf-8?B?SGtueTM4RWRhUWhnSkpWUWMvWjNuNTE1STFJVDRRMWFUOGJsRWlacEVDS2Y1?= =?utf-8?B?QjkyTUxRcFA1VFU4ZncwczVobERGMDh3ck5sSGp5QklIV3dzQVE1UGErMmIx?= =?utf-8?B?RWc2N2dLR25XbnZpWXFNTXY5NTZHZkpwWGY4U0MzNmxjdzdiT2k0MVA5cnc5?= =?utf-8?B?VlZHUW5FNHcvRmhIL2RvNVRJUU9nQlJCZ2xkQ2JBYVA5UWxUWFdwZ1ZaR2hx?= =?utf-8?B?bFNJdEtwUnpodXpBdHI3ZXpmdGMzMnlMUFQxSXRNV2FXcU5jdnZIMWZzdDEr?= =?utf-8?B?c2M5VjRxUkJzM1JXTXNDMzZHbGFNd0krOXZUZjVTRHZlbjdaS2c4TmUrcWU4?= =?utf-8?B?bFpabWlORnp5YXc1akU5RjdSclJwd3JQSm1uNXJZb1BGbWV5UWZnTklJaUsz?= =?utf-8?B?aGNIUWRGaHF4OFBPZGx5Y1J0V1lqWklVa2hWMitSYkhVN1ZsSUV1djRRRmRl?= =?utf-8?B?aEVBSG1sSzFSNUIzc0R6em1nMzRyZUl3TEIxUmNpZm95M0llbzhURzRBeTl5?= =?utf-8?B?K3BXWTZ1cWZDNEJmMEM4VVp5STd4K25zTGd2SzBQV1VOZ3VkTUFmQ1pnOXBs?= =?utf-8?B?K3B0YzNEQ2MrN3hYMmN5Z2hjdDJhYTlnOUpJVEVONEptL2xJemptKzRuK2Rm?= =?utf-8?B?RXVvS2Z3VGtNSzJiYTdxRWQ0U0xJaEpoMnRYVzhyS0trVFBmcnJBMEFucy96?= =?utf-8?B?endiK1lTK1I4Y1ZwZmplSlU0RXQyV25tSU5ybEI2SHc1bnNkWDlmQnkrd1or?= =?utf-8?B?dTlQaWxuaE9NMDBac2JOSWE2V0dWNXhCNWVONDh5QzlPOENzNjNLVlY1MXZR?= =?utf-8?B?QkJpZ1JzWmRQUmtDWmdhNC9ORjVXZUhpTEVtdTlvVjBCQkoyUFYybnRjR2tG?= =?utf-8?B?SnJ0RnhyaDZ5dkViVGxHcnlRS3dBNkpNdUp1NElSYzlqdXhieHhFOWxEOGpv?= =?utf-8?B?V0Jsb2d3bElva0JYSU5EYXlneTVZRU5BdFlOM3RQVUc3c0dzZVYrTlY0U3VQ?= =?utf-8?B?WXVjZTJPRExSSjN5UkpCbytORFFLV0VkVzkxVFd3QlNXMWxzUVQ1RnZzOE9D?= =?utf-8?B?UG5RdHVyTGE1SmxVOG1aTmo2a1dFc1UxUGt6a0RnRnRTYVFVZm1ybFQ4N3dq?= =?utf-8?B?eUdKT05TNWZ4VlRlOTJiVTlLRW00M2hCTHVZQmI4TjJmR1pkOWM2ZkJEdThy?= =?utf-8?B?RWh4aFQ3RXVyZ21ZVlhuMHQzS1Vwa25ubEpraDJiT0x2dldTRklORytEWUQy?= =?utf-8?B?MW5RSjJLMUIzQ1U5UU0wcS93clJkdzRpc3Z3ZDBaS0ZxRGxsS1lrVFBQbFdt?= =?utf-8?B?VzZtS2owUHVkNm0rNTJQbHFnUnFWaFpiUmY5dWdhcjdqUEhiOWFmcHBtajlP?= =?utf-8?B?K29JZ0hITzFhcy9VMUpvWVc2cHpMTHIzcHE4eGFQRFZydlFMUmhMMEhWc2o2?= =?utf-8?B?VEM5N0twemppVkxzWVVpdzYraW8zTnNUMmFuK1ZlUkZDejk0OTlKMjl1R0cz?= =?utf-8?B?TDJ1Qnh0bS90Znloci9LR0VxcnUwYk5ZZFgyM0gxeFhFRkRVMzNycnBxMG9M?= =?utf-8?B?eEExZDVsUnBGWXhaa2lFOElQczJrSkJWTUY3b1A2M3cwaUVUWDJNVEgrdU82?= =?utf-8?B?aUc3MVQ4M0hiZUVpQmdvai9PMzMxVEtzdjM0Sm11Ky93YXBzY2JiaU0yVEN0?= =?utf-8?B?U1dUZnc5aUltbTB4bzVhSldRTzI2K0dBL252ZE8vTkNRR3U5eE9rV2RDaHJs?= =?utf-8?B?SDJ1TWZLME92Wm9nMlZXc0dCb2srMllwcHBZTVdpWm5ZK3lyV0FveXh0Nks3?= =?utf-8?B?YXhDMTVUNnl4WENkMjQxWm1hY2E4ZUJQYjBrZ0E4K0JiU1owSFV2Q3ZKVVRh?= =?utf-8?B?alErTVIvbGpzR0NDeDBVZGNwMDZveTF5OHZSNVBHQ3VRVmpMVjZ3d2o0U0o4?= =?utf-8?B?eTVJWG5xR0pXa0V5TlVFZ3llNXgzdVJRdE5NVVNKRXlrNklSRk90TzFFRTY5?= =?utf-8?B?RWpDcXhxWFNaQXV0VlRMRzNESUZDaWxPMzhFZitzMkV5eWtJUGt6MExMMDRN?= =?utf-8?B?bGliUEh0aHZVcStzMEhRRUUwVmpEOWRQcndTSmt2RFBZaGNzZUU2aGxTdm9I?= =?utf-8?B?ZVpoTTF2WlV1cDREVk1yOVFtK1FSYVBEL25Cdk1SdEtFc3c4ZVJ4RTdxVjRI?= =?utf-8?B?UGo2L050aUd6Tmo4TGp4emlXeEJkTEZ3Y1o3aHhKazJUQ2VVblZLaTF6T2Vw?= =?utf-8?B?aXFmclpNYkt6TDNCMlFHRExiQm45bmRkblk4cXVKQ2N5U2Qwd1JYS0dTcWs5?= =?utf-8?Q?L+cNeqFeUpTLVKyYp5fspK2Els8fLXV6rdUCeBDkzHyg2?= X-MS-Exchange-AntiSpam-MessageData-1: TpMsoxzDmZaGKA== X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61ba6682-7d2b-45f9-aaa2-08df1e352587 X-MS-Exchange-CrossTenant-AuthSource: YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2026 14:22:52.3253 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TMi0/dIoqmFu/TolTCc/7glCYbz47TTxqGq/eKj5UUPUxgi1K4+T94HZ+U+3KS7m+WJmHPToK1kTDxC7cFLSVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQ1PR01MB686067 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 On 2026-09-29 07:38, Joos, Christina wrote: >> -----Original Message----- >> From: Andrew Burgess >> Sent: Dienstag, 29. September 2026 11:38 >> 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 >> >> 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=R2XE72 >> T2tL1ZaTnY93zW2J5-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 > > I plan to look at this in a few hours, but since Andrew has already approved it, it's of course fine with me if you go ahead. > This is probably a bit urgent. You can take the time to review it, it won't make a difference whether we merge this today or later this week. > Since x32 is mentioned here, just FYI, in case you haven't seen it: > https://www.phoronix.com/news/Linux-x32-ABI-2026 Indeed, I just looked into it because someone mentioned it in the bug. Simon