From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MLqpFjZdHWS5LRgAWB0awg (envelope-from ) for ; Fri, 24 Mar 2023 04:20:06 -0400 Received: by simark.ca (Postfix, from userid 112) id 57D581E223; Fri, 24 Mar 2023 04:20:06 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=WhsU7z0A; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,UNPARSEABLE_RELAY,URIBL_BLOCKED, WEIRD_PORT autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5984C1E0D2 for ; Fri, 24 Mar 2023 04:20:05 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C51C03858422 for ; Fri, 24 Mar 2023 08:20:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C51C03858422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679646004; bh=YNtga28+haN4lJcRofMpkOBjUIG/KflDlAv0+Ie4+2I=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=WhsU7z0A6v2YLD4nJlz6AvRq1P3rJ5l87s9nLIuHawYNzg2BsqYQ/j7MyAvMUZ8bi zZx0kHmrWJS3Nwl5EcyRIL+bYSgBua2fmccQATFKMjPT1rRKCafvV677fgtww0N0TA 12ls0qszVG4aReofiY98BAj3vwhwAS/GNwS4IJj8= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2057.outbound.protection.outlook.com [40.107.20.57]) by sourceware.org (Postfix) with ESMTPS id 3F7C13858D28 for ; Fri, 24 Mar 2023 08:19:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F7C13858D28 Received: from DB8PR04CA0008.eurprd04.prod.outlook.com (2603:10a6:10:110::18) by PAXPR08MB7366.eurprd08.prod.outlook.com (2603:10a6:102:227::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.38; Fri, 24 Mar 2023 08:19:30 +0000 Received: from DBAEUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:110:cafe::e0) by DB8PR04CA0008.outlook.office365.com (2603:10a6:10:110::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.38 via Frontend Transport; Fri, 24 Mar 2023 08:19:30 +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 DBAEUR03FT041.mail.protection.outlook.com (100.127.142.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6222.22 via Frontend Transport; Fri, 24 Mar 2023 08:19:30 +0000 Received: ("Tessian outbound 0df938784972:v135"); Fri, 24 Mar 2023 08:19:30 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5128cba85eaa74eb X-CR-MTA-TID: 64aa7808 Received: from a86f1fc302d8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6630B7B8-80F6-44EA-9F1E-7E990D1336B8.1; Fri, 24 Mar 2023 08:19:23 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a86f1fc302d8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Mar 2023 08:19:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E+nSK0ED0Dp2yH9EwixfUZ7lQhg8BitK6UItkcAsx8wsBuruLqwQ7vUEKvdU99igmqCXOr4CMYEBXNYxtkzb8uOPs0CdvGqp//h8VhkbB5Uzxw0j8Ajg8n+xcDkxImaKDhFQ5e+UVwiQ79qf/sy+dnWfzQ0MXjwmUogQt0RCDSuxn28rPSUP5jKW7u/0GTehCHHEftSdoAeJkms/EZtqOtzlwSPXFoArvb86ZoDEa2VoE5lcwUGJ+4CBr7vzEHHaK3oWf+myQPEIatZbMK57ysHh7p8/h8MdbA/lcT9LAATfHlb6ZaDbvXcrQC2HZlrhZO2tRjm4kuWTzSIGPM8gjw== 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=YNtga28+haN4lJcRofMpkOBjUIG/KflDlAv0+Ie4+2I=; b=hGsSKyTYAX+m0u3TspzwTPpC/jeWfMH0mWo5AwrKILL0YXvlDAFNIXAEZq6UCLizEBPkT3uDfKgmvAdquW+QXnUyvIuIoCUaUm3q6AriUuq2ycWCbGW36Vy3aV9itOIXkJGEdoXG4sVwvNx1hVcKhixRPvh59oHGtGZ0CpLBMebui7Q3l4Xh7n9jRg0MoqoEhEsKmNUwSWr2hsOlnR53Z5GRVFzRAJDD2Pp//PAxg1uiJUU6AXJDD+4ntJjyswYqI8FEQmiJI1GliATGZQR0Fp+wE/T/p4209KdgN7dinng3x4lZS7CkqPofCY5okCPkaoC7yCKxfWxQIWbBQZxjhw== 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 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 AS2PR08MB10207.eurprd08.prod.outlook.com (2603:10a6:20b:647::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.38; Fri, 24 Mar 2023 08:19:21 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::bced:32a3:b77e:90a6%5]) with mapi id 15.20.6178.038; Fri, 24 Mar 2023 08:19:21 +0000 Message-ID: <4d11398a-37a7-7f3e-66d1-a423694e24ef@arm.com> Date: Fri, 24 Mar 2023 08:19:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH, v2] aarch64: Check for valid inferior thread/regcache before reading pauth registers Content-Language: en-US To: gdb-patches@sourceware.org, aburgess@redhat.com, simon.marchi@polymtl.ca, pedro@palves.net Cc: marcan@marcan.st References: <20230316103904.1947447-1-luis.machado@arm.com> <20230323105619.9151-1-luis.machado@arm.com> In-Reply-To: <20230323105619.9151-1-luis.machado@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SA9PR13CA0147.namprd13.prod.outlook.com (2603:10b6:806:27::32) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS2PR08MB10207:EE_|DBAEUR03FT041:EE_|PAXPR08MB7366:EE_ X-MS-Office365-Filtering-Correlation-Id: 62511286-3d65-4b79-b0d1-08db2c407de3 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: Cdp5pFBT3apFNFZ03b2HKrZFkTGzRextfVybTNxb7ll47BoQTlHcOe4BXyuNNxvlaYjPk4gg8KgC8HqjcDRuuqAvtcODijN3tSxE2aOp/tW2yYe07VYG2qpw1YmEGK5XnXisHEJPNQJGsKiyNMWHMO80nWoUbyafp6r+dJP5C+LH7jZbg39ZTEGXyOJRgw5bqnpEdfgyuviT0CyiAfINedlU6odEJCvdBl9Pk+l5aPy621ueXfixTUjmVBUPzeKON2Mt7TkWPwxtr24KIDS8Hfs7krF5nl27S19Ze8n+YpYbhGcnsqv8AwvVwpOi5VuMJMez/x50ITxoJlajjJWGIvEogvgivAh9e13YgIfnDAfng24eYlf14g4nvdGrcfPIb9WrcOL/yYH1E6YTu1/9uwX0xrNbNF7rA3Yg1smVS/6rmMpfcIMuGEMNkLSGpKMd4JSuMRxJ4bfQu4NqZkpXGMbWzbNvtIWIMe62syazkm8j5KJdD+268UIOy9b/t+FbPOCbXySKB+weGei6ice6Z48U7KsZOzQyBVmypyDaAcuEZ4bPtfnKqeIGarmACe8MxyS0ylCwoAH6R9vMW4uyOMenzw4YSG/3G9gs3jwoiWNtD5E9nWyuGNWqqERXLsvV2RAZDyODlVNX07ky0qyXu+nWxgd4+IfxTQ3KDacug30= 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:(13230025)(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(451199018)(84970400001)(31686004)(8936002)(66946007)(66476007)(66556008)(41300700001)(4326008)(8676002)(86362001)(36756003)(38100700002)(6506007)(53546011)(6512007)(31696002)(6666004)(26005)(83380400001)(186003)(2616005)(316002)(6486002)(19627235002)(478600001)(2906002)(5660300002)(44832011)(30864003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10207 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: DBAEUR03FT041.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 3a59c6f3-9239-4bfe-5567-08db2c407869 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xPueIF3t12ZWxjEKV9rbo8RlgFHfNh2Y7nebQiFNjm2NsmBAIOaiXywqgnOJg+MaEhsBQc2U6b7wJY03ULYqQNj4MlWp0YWwlhmPzThzDQFsQOH3do6IZMmKrRU+4sdC1phJF+LUciCdwVb/DIxWBiABizXOgq+nP0GLJR8iY2jQt5zrYJatI6RVQdoQxP1v2jZMwb+ZfvL8XQLNcrGEIa/3QN0B6rpW97V9Bb0fTXMxsTlj/yLT+dCSEH7Q2q1GS4IgsAYBlgDuLtgKCIYo+OmZWykG+NTR3an1gmrTPnqnR/7/J/cwofLoS2vjVRrfQZNGMZqbZ3XQnHF4h/HsaGskydTT226X50Os6KTtE5mDH6bky6p8KzQPFKcqeA9eelmUn7RVlpH+SsySryvkwO+QmEnpbShtMDulwrlx2dix6xjWHEYpE8XAMgzbNJa9V0sclc0Qf2+pBO/QADa+yCfXHahGNbqhJJ4rf/TwxW1yhtLcwI36x7gx3l5ML2T3MAIm6uYzzcOGFwpwVuW8fxkANkjQu0jEv4MnAf8LggQJmOOuKrL4KgI2/9CYSJG0jfYJbSVbCzu69XrUJUkEtVJ7Ktb1qoz+7snfYW+XJdTDCIiVKhqWhseVcd3Oz5+7LACA1EuMAle+jUFOCYdxCyJQLZX1naZ42wsUmJ3BsxekVxTtVGzPj6iN9J8BdqhXISEK3l4iUfV5vdrXtHBrrzaowlpw7xkKzBIpvSOiIcFykDfBGTTd/r+/OrIreJwyUZjFUCI4yV+YabBEfAfL4w== 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:(13230025)(4636009)(396003)(136003)(39860400002)(346002)(376002)(451199018)(36840700001)(40470700004)(46966006)(186003)(8936002)(31686004)(84970400001)(31696002)(36860700001)(4326008)(8676002)(2616005)(86362001)(41300700001)(70206006)(70586007)(336012)(26005)(6512007)(6506007)(53546011)(107886003)(356005)(82310400005)(2906002)(5660300002)(6666004)(30864003)(40460700003)(19627235002)(47076005)(82740400003)(478600001)(6486002)(44832011)(81166007)(316002)(40480700001)(83380400001)(36756003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2023 08:19:30.4660 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 62511286-3d65-4b79-b0d1-08db2c407de3 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: DBAEUR03FT041.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7366 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, On 3/23/23 10:56, Luis Machado via Gdb-patches wrote: > Changes in v2: > > - Dropped helper functions and used inferior_ptid/current_inferior () > instead. Changes are now aarch64-specific. > > There were reports of gdb throwing internal errors when calling > inferior_thread ()/get_current_regcache () on a system with > Pointer Authentication enabled. > > In such cases, gdb produces the following backtrace: > > ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > ----- Backtrace ----- > 0xaaaae04a571f gdb_internal_backtrace_1 > ../../../repos/binutils-gdb/gdb/bt-utils.c:122 > 0xaaaae04a57f3 _Z22gdb_internal_backtracev > ../../../repos/binutils-gdb/gdb/bt-utils.c:168 > 0xaaaae0b52ccf internal_vproblem > ../../../repos/binutils-gdb/gdb/utils.c:401 > 0xaaaae0b5310b _Z15internal_verrorPKciS0_St9__va_list > ../../../repos/binutils-gdb/gdb/utils.c:481 > 0xaaaae0e24b8f _Z18internal_error_locPKciS0_z > ../../../repos/binutils-gdb/gdbsupport/errors.cc:58 > 0xaaaae0a88983 _Z15inferior_threadv > ../../../repos/binutils-gdb/gdb/thread.c:86 > 0xaaaae0956c87 _Z20get_current_regcachev > ../../../repos/binutils-gdb/gdb/regcache.c:428 > 0xaaaae035223f aarch64_remove_non_address_bits > ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572 > 0xaaaae03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm > ../../../repos/binutils-gdb/gdb/gdbarch.c:3109 > 0xaaaae0a692d7 memory_xfer_partial > ../../../repos/binutils-gdb/gdb/target.c:1620 > 0xaaaae0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm > ../../../repos/binutils-gdb/gdb/target.c:1684 > 0xaaaae0a69e9f target_read_partial > ../../../repos/binutils-gdb/gdb/target.c:1937 > 0xaaaae0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml > ../../../repos/binutils-gdb/gdb/target.c:1977 > 0xaaaae0a69937 _Z18target_read_memorymPhl > ../../../repos/binutils-gdb/gdb/target.c:1773 > 0xaaaae08be523 ps_xfer_memory > ../../../repos/binutils-gdb/gdb/proc-service.c:90 > 0xaaaae08be6db ps_pdread > ../../../repos/binutils-gdb/gdb/proc-service.c:124 > 0x40001ed7c3b3 _td_fetch_value > /build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115 > 0x40001ed791ef td_ta_map_lwp2thr > /build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194 > 0xaaaae07f4473 thread_from_lwp > ../../../repos/binutils-gdb/gdb/linux-thread-db.c:413 > 0xaaaae07f6d6f _ZN16thread_db_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE > ../../../repos/binutils-gdb/gdb/linux-thread-db.c:1420 > 0xaaaae0a6b33b _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE > ../../../repos/binutils-gdb/gdb/target.c:2586 > 0xaaaae0789cf7 do_target_wait_1 > ../../../repos/binutils-gdb/gdb/infrun.c:3825 > 0xaaaae0789e6f operator() > ../../../repos/binutils-gdb/gdb/infrun.c:3884 > 0xaaaae078a167 do_target_wait > ../../../repos/binutils-gdb/gdb/infrun.c:3903 > 0xaaaae078b0af _Z20fetch_inferior_eventv > ../../../repos/binutils-gdb/gdb/infrun.c:4314 > 0xaaaae076652f _Z22inferior_event_handler19inferior_event_type > ../../../repos/binutils-gdb/gdb/inf-loop.c:41 > 0xaaaae07dc68b handle_target_event > ../../../repos/binutils-gdb/gdb/linux-nat.c:4206 > 0xaaaae0e25fbb handle_file_event > ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:573 > 0xaaaae0e264f3 gdb_wait_for_event > ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:694 > 0xaaaae0e24f9b _Z16gdb_do_one_eventi > ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:217 > 0xaaaae080f033 start_event_loop > ../../../repos/binutils-gdb/gdb/main.c:411 > 0xaaaae080f1b7 captured_command_loop > ../../../repos/binutils-gdb/gdb/main.c:475 > 0xaaaae0810b97 captured_main > ../../../repos/binutils-gdb/gdb/main.c:1318 > 0xaaaae0810c1b _Z8gdb_mainP18captured_main_args > ../../../repos/binutils-gdb/gdb/main.c:1337 > 0xaaaae0338453 main > ../../../repos/binutils-gdb/gdb/gdb.c:32 > --------------------- > ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) > > We also see failures across the testsuite if the tests get executed on a target > that has native support for the pointer authentication feature. But > gdb.base/break.exp and gdb.base/access-mem-running.exp are two examples of > tests that run into errors and internal errors. > > This issue started after commit d88cb738e6a7a7179dfaff8af78d69250c852af1, which > enabled more broad use of pointer authentication masks to remove non-address > bits of pointers, but wasn't immediately detected because systems with native > support for pointer authentication are not that common yet. > > The above crash happens because gdb is in the middle of handling an event, > and do_target_wait_1 calls switch_to_inferior_no_thread, nullifying the > current thread. This means a call to inferior_thread () will assert, and > attempting to call get_current_regcache () will also call inferior_thread (), > resulting in an assertion as well. > > target_has_registers was one function that seemed useful for detecting these > types of situation where we don't have a register cache. The problem with that > is the inconsistent state of inferior_ptid, which is used by > target_has_registers. > > Despite the call to switch_to_no_thread in switch_to_inferior_no_thread from > do_target_wait_1 in the backtrace above clearing inferior_ptid, the call to > ps_xfer_memory sets inferior_ptid momentarily before reading memory: > > static ps_err_e > ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr, > gdb_byte *buf, size_t len, int write) > { > scoped_restore_current_inferior restore_inferior; > set_current_inferior (ph->thread->inf); > > scoped_restore_current_program_space restore_current_progspace; > set_current_program_space (ph->thread->inf->pspace); > > scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid); > inferior_ptid = ph->thread->ptid; > > CORE_ADDR core_addr = ps_addr_to_core_addr (addr); > > int ret; > if (write) > ret = target_write_memory (core_addr, buf, len); > else > ret = target_read_memory (core_addr, buf, len); > return (ret == 0 ? PS_OK : PS_ERR); > } > > Maybe this shouldn't happen, or maybe it is just an unfortunate state to be > in. But this prevents the use of target_has_registers to guard against the > lack of registers, since, although current_thread_ is still nullptr, > inferior_ptid is valid and is not null_ptid. > > There is another crash scenario after we kill a previously active inferior, in > which case the gdbarch will still say we support pointer authentication but we > will also have no current thread (inferior_thread () will assert etc). > > If the target has support for pointer authentication, gdb needs to use > a couple (or 4, for bare-metal) mask registers to mask off some bits of > pointers, and for that it needs to access the registers. > > At some points, like the one from the backtrace above, there is no active > thread/current regcache because gdb is in the middle of doing event handling > and switching between threads. > > Simon suggested the use of inferior_ptid to fetch the register cache, as > opposed to relying on the current register cache. Though we need to make sure > inferior_ptid is valid (not null_ptid), I think this works nicely. > > With inferior_ptid, we can do safety checks along the way, making sure we have > a thread to fetch a register cache from and checking if the thread is actually > stopped or running. > > The following patch implements this idea with safety checks to make sure we > don't run into assertions or errors. If any of the checks fail, we fallback to > using a default mask to remove non-address bits of a pointer. > > I discussed with Pedro the possibility of caching the mask register values > (which are per-process and can change mid-execution), but there isn't a good > spot to cache those values. Besides, the mask registers can change constantly > for bare-metal debugging when switching between exception levels. > > In some cases, it is just not possible to get access to these mask registers, > like the case where threads are running. In those cases, using a default mask > to remove the non-address bits should be enough. > > This can happen when we let threads run in the background and then we attempt > to access a memory address (now that gdb is capable of reading memory even > with threads running). Thus gdb will attempt to remove non-address bits > of that memory access, will attempt to access registers, running into errors. > > Regression-tested on aarch64-linux Ubuntu 20.04. > --- > gdb/aarch64-tdep.c | 88 ++++++++++++++++++++++++++++++++-------------- > 1 file changed, 62 insertions(+), 26 deletions(-) > > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c > index 5b1b9921f87..d11d8320799 100644 > --- a/gdb/aarch64-tdep.c > +++ b/gdb/aarch64-tdep.c > @@ -55,6 +55,9 @@ > #include > #include > > +/* For inferior_ptid and current_inferior (). */ > +#include "inferior.h" > + > /* A Homogeneous Floating-Point or Short-Vector Aggregate may have at most > four members. */ > #define HA_MAX_NUM_FLDS 4 > @@ -3556,40 +3559,73 @@ aarch64_stack_frame_destroyed_p (struct gdbarch *gdbarch, CORE_ADDR pc) > static CORE_ADDR > aarch64_remove_non_address_bits (struct gdbarch *gdbarch, CORE_ADDR pointer) > { > - aarch64_gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > - > /* By default, we assume TBI and discard the top 8 bits plus the VA range > - select bit (55). */ > + select bit (55). Below we try to fetch information about pointer > + authentication masks in order to make non-address removal more > + precise. */ > CORE_ADDR mask = AARCH64_TOP_BITS_MASK; > > - if (tdep->has_pauth ()) > + /* Check if we have an inferior first. If not, just use the default > + mask. > + > + We use the inferior_ptid here because the pointer authentication masks > + should be the same across threads of a process. Since we may not have > + access to the current thread (gdb may have switched to no inferiors > + momentarily), we use the inferior ptid. */ > + if (inferior_ptid != null_ptid) > { > - /* Fetch the PAC masks. These masks are per-process, so we can just > - fetch data from whatever thread we have at the moment. > - > - Also, we have both a code mask and a data mask. For now they are the > - same, but this may change in the future. */ > - struct regcache *regs = get_current_regcache (); > - CORE_ADDR cmask, dmask; > - int dmask_regnum = AARCH64_PAUTH_DMASK_REGNUM (tdep->pauth_reg_base); > - int cmask_regnum = AARCH64_PAUTH_CMASK_REGNUM (tdep->pauth_reg_base); > - > - /* If we have a kernel address and we have kernel-mode address mask > - registers, use those instead. */ > - if (tdep->pauth_reg_count > 2 > - && pointer & VA_RANGE_SELECT_BIT_MASK) > + /* If we do have an inferior, attempt to fetch its thread's thread_info > + struct. */ > + thread_info *thread > + = find_thread_ptid (current_inferior ()->process_target (), > + inferior_ptid); > + > + /* If the thread is running, we will not be able to fetch the mask > + registers. */ > + if (thread != nullptr && thread->state != THREAD_RUNNING) > { > - dmask_regnum = AARCH64_PAUTH_DMASK_HIGH_REGNUM (tdep->pauth_reg_base); > - cmask_regnum = AARCH64_PAUTH_CMASK_HIGH_REGNUM (tdep->pauth_reg_base); > - } > + /* Otherwise, fetch the register cache and the masks. */ > + struct regcache *regs > + = get_thread_regcache (current_inferior ()->process_target (), > + inferior_ptid); > + > + /* Use the gdbarch from the register cache to check for pointer > + authentication support, as it matches the features found in > + that particular thread. */ > + aarch64_gdbarch_tdep *tdep > + = gdbarch_tdep (regs->arch ()); > > - if (regs->cooked_read (dmask_regnum, &dmask) != REG_VALID) > - dmask = mask; > + /* Is there pointer authentication support? */ > + if (tdep->has_pauth ()) > + { > + CORE_ADDR cmask, dmask; > + int dmask_regnum > + = AARCH64_PAUTH_DMASK_REGNUM (tdep->pauth_reg_base); > + int cmask_regnum > + = AARCH64_PAUTH_CMASK_REGNUM (tdep->pauth_reg_base); > + > + /* If we have a kernel address and we have kernel-mode address > + mask registers, use those instead. */ > + if (tdep->pauth_reg_count > 2 > + && pointer & VA_RANGE_SELECT_BIT_MASK) > + { > + dmask_regnum > + = AARCH64_PAUTH_DMASK_HIGH_REGNUM (tdep->pauth_reg_base); > + cmask_regnum > + = AARCH64_PAUTH_CMASK_HIGH_REGNUM (tdep->pauth_reg_base); > + } > > - if (regs->cooked_read (cmask_regnum, &cmask) != REG_VALID) > - cmask = mask; > + /* We have both a code mask and a data mask. For now they are > + the same, but this may change in the future. */ > + if (regs->cooked_read (dmask_regnum, &dmask) != REG_VALID) > + dmask = mask; > > - mask |= aarch64_mask_from_pac_registers (cmask, dmask); > + if (regs->cooked_read (cmask_regnum, &cmask) != REG_VALID) > + cmask = mask; > + > + mask |= aarch64_mask_from_pac_registers (cmask, dmask); > + } > + } > } > > return aarch64_remove_top_bits (pointer, mask); Unless there are objections to the strategy used in the patch, I'm planning on pushing this later today and also pushing a backport to gdb 13.1 (where this code is linux-specific).