From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1xzjLfuoHWRdYxgAWB0awg (envelope-from ) for ; Fri, 24 Mar 2023 09:43:23 -0400 Received: by simark.ca (Postfix, from userid 112) id AE6DD1E223; Fri, 24 Mar 2023 09:43:23 -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=ivPVDDd7; 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=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY,URIBL_BLOCKED,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 35FF31E0D3 for ; Fri, 24 Mar 2023 09:43:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ADA30385B52D for ; Fri, 24 Mar 2023 13:43:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ADA30385B52D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679665401; bh=pdsub+t2EqQvVFP3qsigsHRShKhznn5PQo9PV/m4xbY=; 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=ivPVDDd7QuYRmtoldFYnlceQ1dh5eSHEl7UpQiiJZpdAdkDgQpU+0mdV/xIkE6FHS 9kBPk3TYkX/R26gAUxcuKI21wJ/6dRLtNUX+AhprFkpi7ET4u+c4LcrFq6ZLrmJ15G e+OWG3b2IhCW1CY80CBrpJG/REhD/RaBAEUzJ954= Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2088.outbound.protection.outlook.com [40.107.21.88]) by sourceware.org (Postfix) with ESMTPS id BF7D2385843A for ; Fri, 24 Mar 2023 13:42:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF7D2385843A Received: from DB8P191CA0022.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:130::32) by AM9PR08MB6132.eurprd08.prod.outlook.com (2603:10a6:20b:2d7::8) 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 13:42:53 +0000 Received: from DBAEUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:130:cafe::fa) by DB8P191CA0022.outlook.office365.com (2603:10a6:10:130::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.39 via Frontend Transport; Fri, 24 Mar 2023 13:42:53 +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 DBAEUR03FT042.mail.protection.outlook.com (100.127.142.143) 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 13:42:53 +0000 Received: ("Tessian outbound 3570909035da:v136"); Fri, 24 Mar 2023 13:42:53 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8298b3cf9f644963 X-CR-MTA-TID: 64aa7808 Received: from bfe88a6c9d2a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id DCFC02FF-3AA5-4972-B288-5EEEB7F01CCA.1; Fri, 24 Mar 2023 13:42:46 +0000 Received: from EUR02-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id bfe88a6c9d2a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Mar 2023 13:42:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QTxIaX/cT05sBev9mIj3/bA1Xpf3fCIxW9QzxFYxw6yuq7r7/g95W+tgBFlHBcrSmJHNSBEAMYlr5W1zIPRPosoY1RCLqNoOnnTY97YCMSGJw0FikFGr1+dWNyRIAGVPdpwOUThwAflw1TRQJvz/Lwe1Fp+cnLY77WVfAKq+B74WZTMNLWz1Wsoic4VsTnO+fl26bYsxI9eaClV+kHZ7uUDnepgNI2ziptOlLyrZqmAfFWQjtTqsOi+W1JkHQCfGlI/N7M6PwwnSnUCIe05cJOM+il281SsccDaRQNgHGboLuWTHiBeOHx0sD8q3fVQFJ4r2mlu40i24+czO/xfLYQ== 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=pdsub+t2EqQvVFP3qsigsHRShKhznn5PQo9PV/m4xbY=; b=I28DXfYwY5J6E+mIk80f8kbULYgD6gvzVdCjdXOCKNcGpDLhWpUVVc/rHt4nheruxKzj4i8eOrdN0frwqhZ8+Um4zjORzQGKCtl1nxL/2fzn8dF005uz75Mbeqf856e/0qf015YO6V9wUGsAkre2Mwikco3n7+unEwyo9H4Q4GYeJr2hFFlzxgqfG0NVaRADox2+7VPtF7UBQAdJd22OvK5yQnA9ZULsMwnSCvpRUEFFvyTBA/ktma10eP8eiQ0ibTBrTSVPiI17+FGimisKmDdrUC7lp2qf8vVDrjoUgP+A6O4EcmZ6seuFVCr2piYkmLlKe0rg8DHsybh55n4S0Q== 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 AM9PR08MB6658.eurprd08.prod.outlook.com (2603:10a6:20b:303::14) 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 13:42:44 +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 13:42:44 +0000 Message-ID: Date: Fri, 24 Mar 2023 13:42:40 +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> <4d11398a-37a7-7f3e-66d1-a423694e24ef@arm.com> In-Reply-To: <4d11398a-37a7-7f3e-66d1-a423694e24ef@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LNXP265CA0067.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::31) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AM9PR08MB6658:EE_|DBAEUR03FT042:EE_|AM9PR08MB6132:EE_ X-MS-Office365-Filtering-Correlation-Id: 9c4d5a6f-8a51-4436-6346-08db2c6dab1a 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: D/sosMnXbb58w7QGxkdg8G7dGvcXOYi3RFe4LVGAkmL7sENz5StcMef/2UVkxqKLXDjiXUsqolvntnkqSilGirNtlh2dLNRRKQEvV6lZhIN+0HB48tD8lv2rAWv6yhHC5PRqqppWOGO0XpalwOnPfpH3RRvO55GJ3UrM0g1gpIeyGRvAva/0P66TdSrUTYQH74IJFsAfLK/TVIaH9LP7MmJCjFq4NVpqJlQIPi8i83zww/PybWI3XdBxRpFTiQniHc+ZkrntdlVram3uFXILEbmLuvjKrEHyqWdcgj0a58HQo5YVhKR+UDivDPMBnfaNWN7WQULkmqMKzx32ZemTj5K8u7BWZracBNj1AKRXfbpBZExPsaPsOAFHJWk7K3oCRM/CVa3x/5xT29Ngp4KTkNJ7VVeJ7ylwIU40ufSNQdvtqJ5AVeDRgwG+KITeplu6NBr2od4X9AlJ5EcqEAuVzp5oZ7ELTYm0bgbHhb5BOCO5YJjpCSetr7x3AD0/Vd4L2FTs+UZfGj2RICh3GD1qF7FnqjXbaDd+VtztyC4cSPn70EFSdDVWRxwcYUPIyg2riSbzT4Lb3h3xrtqrWTRKBXvW9yxF/NTlVu9AodTJ1XZAhuoA4iVcdqUfP+4ZIq65iRh8Zsf5pMoeAXXnwY0zclazTBWKF5KDX9L/6mpjFBg= 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)(396003)(346002)(136003)(366004)(376002)(39860400002)(451199018)(31686004)(38100700002)(2906002)(83380400001)(84970400001)(6486002)(478600001)(186003)(2616005)(31696002)(86362001)(36756003)(19627235002)(66556008)(8676002)(4326008)(5660300002)(30864003)(66946007)(66476007)(53546011)(8936002)(6506007)(26005)(6512007)(6666004)(316002)(41300700001)(44832011)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6658 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: DBAEUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 664b85f9-8292-45a0-6003-08db2c6da54d X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eGe/VcM3PWf9FKV+3gwnuT4OXJp6H86B7qInym/FbVlremQCHWj7GCykc3b/3WMUZIpRLnPNBmUEnGQKMoPtYOfrS2Np202vkt3KV1zMuMC0YJJxtAfey5WsOSgv3isdA7eHTm2oMl8rY8t152OQkih6Pk4wOxe9esEzbs35vPUp7lEmn2T+w15y1Ye94y9IBwwI1spLyNc5Kxk0FKAmt/TwSHNEypTy6Gqbt8QkPBhuQE2NAa72+tUozfHpoWGbQXay4ySCPc31pqZT002JOBiOVJJBK2LZ3fBg9B6er7w1wL6GjNr5pST058PDy6v+2nu7ABMjh8oSLKhLlbQNF5o/T3LKm3cheBGbMGCLxbJeo94Kr6s4ZvSNITYKyNJC2/JDVL8ALTDk3G2OvzIpm9g8+UkbNLIZjT6gfeD5g/apSnqYarD0zK7HkYADOHRBAB1s3KmXvY7k6pA9D0Sablzg4inPT2UojyeezakksqtKg81rrw6b5t93fjqJcoFtu7X1PN0zV9up3dpF19Y59xykxyYUjKKt/pQhjj9pwQ71tk5s9n81yRRRcq88DHcqRjU4WP4OvLIHBKcbDahdPunAyVfl+bjpJZe/jAL0uA/sXGg1s0rb8zM4UCzcJHgcbQHlEM9Gwro8386RT4G12HC/1eI3zSUZl3b/MuyLM6dL9bsGdJ/bw4O45Bc0zeZv3ZHVrAZsIYbbi13ZP8YP46NUvsmiNKETWcEieHv6VwNVkP8B6MSmuV4PpjvxNEsM 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)(346002)(396003)(136003)(39860400002)(376002)(451199018)(46966006)(40470700004)(36840700001)(84970400001)(31686004)(8936002)(70586007)(70206006)(41300700001)(4326008)(8676002)(86362001)(40460700003)(36756003)(81166007)(53546011)(6506007)(6512007)(356005)(31696002)(40480700001)(6666004)(26005)(336012)(47076005)(83380400001)(186003)(82310400005)(2616005)(107886003)(36860700001)(316002)(6486002)(19627235002)(478600001)(5660300002)(82740400003)(44832011)(2906002)(30864003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2023 13:42:53.6747 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9c4d5a6f-8a51-4436-6346-08db2c6dab1a 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: DBAEUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6132 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" On 3/24/23 08:19, Luis Machado via Gdb-patches wrote: > 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). Pushed to master (ef1398987a132769779679fd9ffd353dce840f95) and gdb-13 branch (b3eff3e15576229af9bae026c5c23ee694b90389) now.