From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on2081.outbound.protection.outlook.com [40.107.14.81]) by sourceware.org (Postfix) with ESMTPS id 494E63858D1E for ; Fri, 8 Sep 2023 16:05:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 494E63858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/rWCgIWNo74AlcsAroKTQSir8Avq0/r5V9BXZY2gLFs=; b=nyr8HeOWUaXOQPJdvsA1wvG0Qv+2rT4gsPtqf65UoHxa7jBTHYMRzqWJm5cdR2qHfihM5AHXLIh1Q0qcUZ7xjxaUk/PKMg2qNv5NnDArbRvKSkDL7chSlw1X0lTgpy8sMof2e84LsEVMksfQrXmFZZ1tyvKhDK7I326lLzTrbrg= Received: from AS4PR10CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5dc::6) by AS2PR08MB10373.eurprd08.prod.outlook.com (2603:10a6:20b:546::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.30; Fri, 8 Sep 2023 16:05:22 +0000 Received: from AM7EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:5dc:cafe::5c) by AS4PR10CA0006.outlook.office365.com (2603:10a6:20b:5dc::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.30 via Frontend Transport; Fri, 8 Sep 2023 16:05:22 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT064.mail.protection.outlook.com (100.127.140.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.30 via Frontend Transport; Fri, 8 Sep 2023 16:05:21 +0000 Received: ("Tessian outbound 30c9f5e988c5:v175"); Fri, 08 Sep 2023 16:05:21 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 68e8199798eedee3 X-CR-MTA-TID: 64aa7808 Received: from 0ad9410ee98b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 18045123-8348-4FC3-9D51-4111B22FAEEC.1; Fri, 08 Sep 2023 16:05:14 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0ad9410ee98b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 08 Sep 2023 16:05:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A/3L6Q+cSo/ANplRTg5hmm4+wa+YKo07yCGv71/8J0R3Y0+yUsBgF7gOjG1gTWvVZI8mjDhYYyOUQDywXCEbWDNDdbJP2VyUf8l1+jndmOa0L1F2BC6ie9myAOc2nxzk8j8+BUsey00etf/YfznPPhpCMvizGbdQG+GyR3cCsWeQqVqokfcrzO1S63ZxYU0U57hWNcEe+RoVIf5u13pjDc691aWPR60siU29ugYKYOjME2G4eP5UBwuITvfCsVn5iGQBWNi6INj6sDutelO3nW5pZu5DT1aJcOv+IDxk9F6vAEIMTPOpSGuAlSnwx7j+a1T/xuEJXOBKi/gl0Szq8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=/rWCgIWNo74AlcsAroKTQSir8Avq0/r5V9BXZY2gLFs=; b=HScUULfFtQBj+N+imgUfdA0wlkGpczlx7Q6cDoRE2HKTia5L7rR4JPppeYxoYjpJgFhnqc0iQsU7Vn0d3tgtCqb2UFvCEV8HfsQ5fqsw7WdxIguWX//oj+CMxwMWf/L0BYkIWOeq+VmejYhYyfIXSkZzu36XpDzhdPpqt/hHCaKGj06UDX8BK4/6+6dwFps4816cJ7Dr0PCmabvJMuz/Li9SojPvLQry0WUWbWYJtsOjXFotM0sN6sdP6USGeWWETd+GADc2ZlITaPRtNkKXXQ5TU/XtjPT7uaXiU2hO5h1+PUs1GQJH9wHYukB1yr25U00TKBJFZqntX6jgfTwrog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/rWCgIWNo74AlcsAroKTQSir8Avq0/r5V9BXZY2gLFs=; b=nyr8HeOWUaXOQPJdvsA1wvG0Qv+2rT4gsPtqf65UoHxa7jBTHYMRzqWJm5cdR2qHfihM5AHXLIh1Q0qcUZ7xjxaUk/PKMg2qNv5NnDArbRvKSkDL7chSlw1X0lTgpy8sMof2e84LsEVMksfQrXmFZZ1tyvKhDK7I326lLzTrbrg= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by DB4PR08MB9261.eurprd08.prod.outlook.com (2603:10a6:10:3fa::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.30; Fri, 8 Sep 2023 16:05:13 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7743:60fe:4859:2df2]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7743:60fe:4859:2df2%6]) with mapi id 15.20.6768.029; Fri, 8 Sep 2023 16:05:13 +0000 Message-ID: Date: Fri, 8 Sep 2023 17:05:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH v5 12/16] [gdb/generic] corefile/bug: Use thread-specific gdbarch when dumping register state to core files Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20230907152018.1031257-1-luis.machado@arm.com> <20230907152018.1031257-13-luis.machado@arm.com> <971a9e69-a802-7354-728e-573d4c85c3f9@arm.com> <680b67cc-4330-4425-9860-02666f7d0e0b@polymtl.ca> From: Luis Machado In-Reply-To: <680b67cc-4330-4425-9860-02666f7d0e0b@polymtl.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0074.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bd::13) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DB4PR08MB9261:EE_|AM7EUR03FT064:EE_|AS2PR08MB10373:EE_ X-MS-Office365-Filtering-Correlation-Id: 8a36bdc4-9696-4666-0665-08dbb08567b8 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: /9rwNoPgwYiCQdbJekzgfc2P8rh0WfCkOXHiOM5x7NjjIJ76EPYpOBgdnwZLVeFVHvlMVPz67JlXinj/xjSvqMyZgeN3EN2eMGiAH/Jt5nFxFMxiKKThpLQvmVb/Komta4cHBtqz0AnrP95OLzpIfG6ofW0guG+Eu9X0yoYzVQ9dNQ4xW/TurWBqodzFh6kdZnQeGAEtqvKTwSJVzlB/PXmghjhNxWjMNhqlH7QZYynSn9bhUUg0us2w5EYUH/hh4k3Ld4Lbt/KtkthlPcRZ3L5BO8h66WjWgtPrGKxFMnZ+DREAoF44/1XooYqGKzNwZbEe4GG54KdTxUrw01+Zn/qm6jdoFoHVwx411M448InXw6ITtb7GRFgPxL4fRajW7gDwFRmatzxvBbXHSiry9tqzLAg6i/BtkiJMxmDOW0v+CE7apMMnNaeuOXXu806viCeCqqC4rBh5ywCKUhuIrl0/sDtSHSIY9sjDKcY2w5xovoIa2fLRlmNHLiI/QCviZuMXAARfs3GiQJM27PwsVohjKVvwZLqOPEY626rZwJi2jeo+HFIif/zgfps0wrRMg5wo0cqCVl9VM5q8rOfLIS4iveVA3o5OH8WYkXzIwVE0FnZTi9ycA863eiBC1zHIN8JEXWIH0+IYfSgBYS2QTMT1cANlHGPcU7qZZoalMCU= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3919.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39850400004)(346002)(376002)(396003)(366004)(136003)(186009)(1800799009)(451199024)(2906002)(86362001)(31696002)(53546011)(2616005)(26005)(36756003)(6486002)(478600001)(6506007)(6512007)(38100700002)(83380400001)(4326008)(41300700001)(8936002)(8676002)(44832011)(66476007)(66946007)(66556008)(316002)(5660300002)(31686004)(41533002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB9261 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT064.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 602973bd-f343-46c0-2988-08dbb0856246 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tl29l6wScqF2s/PTyFOykIed4kkqZizmD1WMjfLansfRbZ5qEI4DPP4QKgfka0Xcze8TjF9VHsB9Ckjzrpdj9t8VgnLH7Ry9XMe/Fe+uHzY37NfNtC46EhOQhdYPgJS530ibSccU+Xtku+god7rjT/p5jk8j67pYyDSvLFj+VdH75S5v1eyct004rv8ybDp+PVyBn9Yx2GXVQoPXHlnXcyghjWzwQ9AkrzHA85x4C9tosdpwjC/iFkYoOwmK1eCyumMsJ0EZGl+Yj4WiQKz6u/qyUUrvh4os7xoNULVovGTnPA9odRL1roLeNLSQEgBn2dgk6Mw1J2For85rht2yx4qX0iXDiA+GQKZ/csFT7SKpH3WPhwaxxfbKArjKvmVdGs3jPyypUPUEdx7847xnkywwIKNKQBO8cxRBzqX9CBJOFHC1UVVYERxlqjH/T4IP1Uso3uoaEi/IN4xx/iD+7S2uTijjhE60qIj71QfpnPZzWngH/sHvFPhgklfWy8A8re1AXZKSRrSkwqfAPAJSlsiC3Etns0fF+iBDR11ZQcdk4nzrDgQS7Ns/W8S/mFLzvejW+hBvAGB+Tk/1n9bKM1rpfSOUyeUN3yO9FHthIE3rwbgn0I4T/gYSPpFzW01efvP5w/CieQ9qHRg7UW11YoulMjRjrdO7rei5NK5QMYV19oJvycvdPGi1+9B+vzZkqrotzevdyPr12qgvq8IUsIkO1mdJFCb8tp7V4dv12+vcZDE9l9tz2MqaTBaNh5xQqNi3IbMJoG2/BB79AfAZsGrmG6oAPa6xDcXy9XxSaP0= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(4636009)(346002)(39860400002)(136003)(376002)(396003)(186009)(82310400011)(451199024)(1800799009)(36840700001)(40470700004)(46966006)(356005)(6486002)(6506007)(53546011)(6512007)(478600001)(83380400001)(107886003)(2616005)(336012)(2906002)(44832011)(8676002)(41300700001)(70206006)(70586007)(5660300002)(316002)(4326008)(8936002)(26005)(40480700001)(40460700003)(47076005)(82740400003)(31696002)(36756003)(86362001)(36860700001)(31686004)(81166007)(41533002)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2023 16:05:21.9840 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8a36bdc4-9696-4666-0665-08dbb08567b8 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT064.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10373 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/8/23 16:58, Simon Marchi wrote: > On 9/8/23 07:09, Luis Machado via Gdb-patches wrote: >> Could a global maintainer please go through this change and let me know if it is OK? It touches a generic part of gdb. >> >> Though I don't think it should change the behavior of non-aarch64 targets. >> >> On 9/7/23 16:20, Luis Machado via Gdb-patches wrote: >>> When we have a core file generated by gdb (via the gcore command), gdb dumps >>> the target description to a note. During loading of that core file, gdb will >>> first try to load that saved target description. >>> >>> This works fine for almost all architectures. But AArch64 has a few >>> dynamically-generated target descriptions/gdbarch depending on the vector >>> length that was in use at the time the core file was generated. >>> >>> The target description gdb dumps to the core file note is the one generated >>> at the time of attachment/startup. If, for example, the SVE vector length >>> changed during execution, this would not reflect on the core file, as gdb >>> would still dump the initial target description. >>> >>> Another issue is that the gdbarch potentially doesn't match the thread's >>> real gdbarch, and so things like the register cache may have different formats >>> and sizes. >>> >>> To address this, fetch the thread's architecture before dumping its register >>> state. That way we will always use the correct target description/gdbarch. >>> --- >>> gdb/linux-tdep.c | 18 +++++++++++++++++- >>> 1 file changed, 17 insertions(+), 1 deletion(-) >>> >>> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c >>> index b5eee5e108c..7d0976932c6 100644 >>> --- a/gdb/linux-tdep.c >>> +++ b/gdb/linux-tdep.c >>> @@ -2099,12 +2099,28 @@ linux_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size) >>> stop_signal); >>> >>> if (signalled_thr != nullptr) >>> - linux_corefile_thread (signalled_thr, &thread_args); >>> + { >>> + /* On some architectures, like AArch64, each thread can have a distinct >>> + gdbarch (due to scalable extensions), and using the inferior gdbarch >>> + is incorrect. >>> + >>> + Fetch each thread's gdbarch and pass it down to the lower layers so >>> + we can dump the right set of registers. */ >>> + thread_args.gdbarch = target_thread_architecture (signalled_thr->ptid); >>> + linux_corefile_thread (signalled_thr, &thread_args); >>> + } >>> for (thread_info *thr : current_inferior ()->non_exited_threads ()) >>> { >>> if (thr == signalled_thr) >>> continue; >>> >>> + /* On some architectures, like AArch64, each thread can have a distinct >>> + gdbarch (due to scalable extensions), and using the inferior gdbarch >>> + is incorrect. >>> + >>> + Fetch each thread's gdbarch and pass it down to the lower layers so >>> + we can dump the right set of registers. */ >>> + thread_args.gdbarch = target_thread_architecture (thr->ptid); >>> linux_corefile_thread (thr, &thread_args); >>> } >>> >> > > Makes sense to me: > > Approved-By: Simon Marchi > > I think the linux_corefile_thread_data structure is not useful nowadays. > It was probably used through some callback's void pointer before. But > now linux_corefile_thread could be changed to accept individual > arguments instead, it would make things simpler. Would you mind doing > this change as a cleanup on top of this series? Or you can do it before > if you prefer. > > Please remind me, does an AArch64 core file contain one target > description per thread, to account for the fact that different threads > could have different register layouts? Or right now we just hope that > all threads use the same target description (which might be different > from what the inferior started with)? Right now the answer is no, so this is somewhat broken. We just have the one gdb xml note in the core file instead of per-thread notes. We mostly get away with it because in practice it is difficult to see different vector lengths in each thread. So either we output per-thread gdb xml notes or rely on the thread's register notes to figure out what the proper target description is for each thread. > > Simon