From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2089.outbound.protection.outlook.com [40.107.20.89]) by sourceware.org (Postfix) with ESMTPS id C18C03856258 for ; Wed, 4 May 2022 14:03:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C18C03856258 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=H6AIwu4eWGxVdbD0mVTg/VgrKy87icTny9fEYNllxbI7X4apRjR+EM2++bavs0KZEpc2s0E7YG/a1L1LwF+FAk4Lndojsvtm6jXYWf54dfijyepd/Z2aJ77RA7yghHG91ZWvonbjd7girOiI/Ia7FjGuAJ4d4W08AWSjQGrQb0xXvvOe4gmoA1emV6ER09vp0777EhQSyp+4YrIjE8WCtFHSeZRrg7lQ5I0yvI3aDxIkzTfS9C94fHbhl9Bi0mPDl2WIOvjvVYoxiNY9SXyMyc6OsOVJ5ckshzuwj4dBw3K9j/kLLs0wmwsLjUbWcfhM4YA4MrbncnCjJUb9arKN8A== ARC-Message-Signature: i=2; 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=0CUQPhPnmd2sNiIMQVhCvFB4RPoHxnXuM8zZVIvgIUs=; b=Sm1WSJ24ohIQlxWAAHkLc5CTajrir+WyLiuVU3B+tW4Xd+hhM6+klSWaG33d1g2f8us24Ku8WyYvt8FskblHBDUQI9a+ZVtU/Z4zsymdzwmQzWJy5WhpZ2ZiYhz41yBC//yXFCsmh6Xfx5md7En38+0RbwnvSHeVDtrR+6Okjx3A6VezjG6IYTY4pNHeynGro0cTXyiSSyqzZ3LlqUShgpnK8UsbFNho0mmCDxAjfJssQl4fJ7SfuJh4AD18EN8xK1j/1gMk4LDMaW1rNvKPYjMlUYFc4etvgCA/JdtdZWUEDNA/u2Z8hfhGhZAucPzPX2wsJaBCGD1Ca6IwOiqJiQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from AM6P194CA0100.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::41) by VI1PR0801MB1664.eurprd08.prod.outlook.com (2603:10a6:800:59::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.14; Wed, 4 May 2022 14:03:33 +0000 Received: from VE1EUR03FT039.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8f:cafe::6b) by AM6P194CA0100.outlook.office365.com (2603:10a6:209:8f::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.13 via Frontend Transport; Wed, 4 May 2022 14:03:33 +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; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT039.mail.protection.outlook.com (10.152.19.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.15 via Frontend Transport; Wed, 4 May 2022 14:03:33 +0000 Received: ("Tessian outbound 2d401af10eb3:v118"); Wed, 04 May 2022 14:03:32 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5497752690336b26 X-CR-MTA-TID: 64aa7808 Received: from 1ccff9aa4139.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 566B7F4C-8AD6-43BB-A642-621F63F02FF1.1; Wed, 04 May 2022 14:03:26 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1ccff9aa4139.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 04 May 2022 14:03:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f/R4C5oYAmLSBMcgnDxB2H4LzxcENqZIqLc/VpK4uhSGw5aXehEl0vQhTrAdsSKvxL7m8PlcWZ2fTR0OBvf/4RBLXuBXnRuDf0CFNFDtkMMLa9VcW3LTnPrWQ5M7rnZQgsEIFztYr2/zC1dz/05S/CZFjXC1ZuKemUJbfhRhGSTqCyxcafTUA8NM15afUYCHbgP1dKQDENhEtOb0IExk6oA6+cnPe+zkH/pqldFoqdSspQeZmO6WaSIDwTjjk1p+tL2zArsjyUmw03jXo134M996DG4XnmsNW+rY5zvfANEJd8eHsYBKjR95dHYvo6fw3rBoZQqJCAZKiKi5diSMqQ== 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=0CUQPhPnmd2sNiIMQVhCvFB4RPoHxnXuM8zZVIvgIUs=; b=E55qjVksDt/UYUh+pyODWmP/j6rs3AwHQ6E1VrQAtmtTEvXsB+KaJwaN/2Qu/VNlkEk/RrHY5ugSNRFVI0P5unJyItVQ4Dz0zyV1LN2SLEs0ufBH0rd9ziy6tvhLRR2qp/dhyc0GaQuXhpd4uz7uBOK14T1TOxte2lKJ4WzjXhOIVJjWbv8zGetmPBeyO8b3sw33SGlME2t0JVCPZ5zYL/BCBx2zoilh2UMKSWA5tsJEJsJNswYupjPIOXL5u3ONLBMhtjTixUMDloWRB8v1g5MFLQH7+kfN7opTUpyx2gZaA6YrrA+FvqipxFRZmGl6Isf7s1PPDgSgLDEiP1JF3A== 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 DB6PR0801MB1797.eurprd08.prod.outlook.com (2603:10a6:4:32::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.15; Wed, 4 May 2022 14:03:23 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7080:6233:cf8f:a8a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7080:6233:cf8f:a8a6%7]) with mapi id 15.20.5206.025; Wed, 4 May 2022 14:03:23 +0000 Message-ID: <54def099-6a98-2103-ce45-c6859d938fb0@arm.com> Date: Wed, 4 May 2022 15:03:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 0/2] Fix gdbserver/linux memory access regression Content-Language: en-US To: Pedro Alves , gdb-patches@sourceware.org References: <20220419224739.3029868-1-pedro@palves.net> <26ee78d5-d9ff-3ec3-5767-c6ae8cd5afa0@palves.net> <082d3a0a-f6a4-0e40-4e27-623a9949186c@arm.com> <51c7d9e9-7d84-f826-be2d-be559847da9b@palves.net> <48db3b2b-46e3-1f30-2443-7d4b406b4c46@arm.com> <1b41b921-b79b-6168-96b1-58b9dea5508f@palves.net> <7244be2f-3a26-6f44-0c47-8d86865abfa8@palves.net> From: Luis Machado In-Reply-To: <7244be2f-3a26-6f44-0c47-8d86865abfa8@palves.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN7P222CA0022.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:124::7) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 3d9484af-7e3d-4d70-66f2-08da2dd6e035 X-MS-TrafficTypeDiagnostic: DB6PR0801MB1797:EE_|VE1EUR03FT039:EE_|VI1PR0801MB1664:EE_ X-Microsoft-Antispam-PRVS: 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: fSUG+OVHFVX3xca9N/B51ONdhrohTeL4zt53eAZBIu+cMt2bVQ+PkO2wI4VGmtBSPyeHtXy1iuRm766b3cfRb6OzylG8FdnFkf//u4ZOOaxz/ckbpJr3RaUdcaCTNivOCb82UMZq5C/ps5eXmgXD/vwZ5vjsuDfFhh0IX6Kz4hPKWRh8jetx/8J1Vymc7/ll/Xkr7HEpMFIwH8mA8vW+CkHD4yqOTfMyVFo+8pekYxHmH+BjAaS1saCT6xfgOeq65mWC13MzhXwq8QOqYptlWO/ENGhyXjT/YRJ+EJWpFRyfaK8keOQ5196rG0AyvL/F94yGI7eKJAza6KIndfZuJTVCHuiW+gOv/P2xrAoB9YxNSdBDK5cQAuifP1o6vYCXiKu17rRT/iLak2WXz20iaKwJxSnYoC817K4ahSjVlQQ/TKcgjWunLcQNbbPnXcW697RzS2VQWlvBL6h7IY0+Un4gL3H1/ObRdmsolN65exhn/9FT5BIXAaq9sHRuC0+f21CkJlH/b54hQpiYchzHH1QBaA+9BMot5YYWrGNDyBqYWzYdBSO9vuOo5FsKb5yINPtPIQLuLTGkekrZRufxw2Xtfcakl80q6N0GeRm9py6PTLA1ilRL+77XCi42ZXZuvnHGinTJFFn4tnUYQQbSgi7jFIdCEfrZylB0Fgk+ycwdOTa1omEv2DKX1qhMl5YFWBeDsnJkMIeADiykJZS2fTnhZkeD2d9i329r7sUSBpkDs6H70/o/q/K0YSQytT98mW8FGZBvdV0ZXoXyQa/zJpsdiFtVLc9JZsf31yj5KixaTbXmZF2hANCI/1tEwcnv 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:(13230001)(4636009)(366004)(186003)(316002)(5660300002)(36756003)(53546011)(2616005)(84970400001)(31696002)(86362001)(8676002)(66476007)(66946007)(66556008)(44832011)(2906002)(508600001)(6486002)(38100700002)(8936002)(31686004)(26005)(6506007)(6512007)(6666004)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1797 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: VE1EUR03FT039.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 77f17237-cfc1-4e5a-5034-08da2dd6da04 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: q5tDKNqF1KDWfZ19BBbApLmGWaombrvyS0gCSPc1LS9IONr8Lhjvsq0FHxG/jQ5WlDoBnHvo3evBgwwMuLMdsa6JC7iuCogIhwIEo6OxFV/F6xMIgzAWiHC7ed+DWE/YsMHULETQcFuG1sRjkuBebr/ehxtjWcvIPbFeDpFyYtXEQI+KctMgpqUV//pcLukir8GqGSugtqIdCxUblex1eIwkiZbWxDQjwR3QJxLfEkQxHlh6DU2y2St5FiPiS5swsA/kyLzT98AuYjH+A7a/P1qFrdz8qa4ny/p3aGsf/YjhGxf6aQXvw/0Yc8C7+tNvZ1JBuadubZiv4RTVDuDKD5rdUdPBBbEr12j3OsChF/aeXG2BowKuKqOyHLTgyZMXqEHXeNA79nV4cmIQZ0SOOVq3dSfRiNNzFoiD3SWeScuNZLmpAMar+Oh4TzpfYppBCMMIn0oRipnc3DLJY5xzamBOz9M8Qu1Fz7fpgxl7isVUEO2IIxb4Sq20OFhRTQM3M5mVQebynfR07Hl2PXjabyaQ8Z+o/qayFm9WZSrUaNGyRvvJyt+b+hYjDTAAINNHEwUQRJlAR8mjuP90LyokcZYlzA/fIKBdLR5oiZ2yTTPenqVeLM/cWzPDrosBcxl7K44xvpwpCAU9h91DMLblOdPR8o0BWKODdktg0xddePiQfIPK3evDIqAN2s3Q67Ht3+AVQQcADOfge7iH0IYcwt4mgfReCfQWqf2f1IBRtgsTUvAuBqZH4eUZCdRggyWjd7owRjfgG47/MpvllcRIWh/nYHFD5HIsQ0EbffEnX44= 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:(13230001)(4636009)(36840700001)(46966006)(40470700004)(26005)(84970400001)(316002)(40460700003)(356005)(6512007)(86362001)(2906002)(6666004)(81166007)(31696002)(53546011)(6506007)(47076005)(336012)(2616005)(186003)(82310400005)(83380400001)(8936002)(508600001)(6486002)(5660300002)(36756003)(36860700001)(31686004)(8676002)(70206006)(70586007)(44832011)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2022 14:03:33.2787 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3d9484af-7e3d-4d70-66f2-08da2dd6e035 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: VE1EUR03FT039.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1664 X-Spam-Status: No, score=-14.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 04 May 2022 14:03:40 -0000 On 5/4/22 14:44, Pedro Alves wrote: > On 2022-05-04 11:14, Pedro Alves wrote: >> On 2022-05-04 10:52, Luis Machado wrote: >>> On 5/4/22 10:45, Pedro Alves wrote: >> >>>> Can you show a backtrace?  If this is when reading memory, what code cares whether it's 64-bit?  Reading memory >>>> out of /proc/pid/mem should not care about that. >>> >>> Here it is: >>> >>> #0  thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120 >>> #1  0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31 >>> #2  0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194 >>> #3  0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226 >>> #4  0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226 >>> #5  check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862 >>> #6  0x0000aaaaaaacc660 in read_inferior_memory (memaddr=, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93 >>> #7  0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071 >>> #8  gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048 >>> #9  0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307 >>> #10 handle_serial_event (err=, client_data=) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520 >>> #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700 >>> #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596 >>> #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237 >>> #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518 >>> #15 captured_main (argc=4, argv=) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998 >>> #16 0x0000aaaaaaab66dc in main (argc=, argv=) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084 >>> >>> -- >>> >>> This sequence of functions is invoked due to a series of conditions: >>> >>> 1 - The probe-based breakpoint mechanism failed (for some reason) so ... >>> 2 - ... gdbserver has to know what type of architecture it is dealing with so it can pick the right breakpoint kind, so it wants to check if we have a 64-bit target >>> 3 - To determine the size of a register, we need to fetch the register cache, and we do so through a thread point, which is now nullptr. >>> >> >> Thanks. I believe the patch below should fix that particular instance. >> > > Luis confirmed this looks good to him on IRC, so I've merged it, as below. > > From 5890af36e5112bcbb8d7555e63570f68466e6944 Mon Sep 17 00:00:00 2001 > From: Pedro Alves > Date: Wed, 4 May 2022 11:09:07 +0100 > Subject: [PATCH] Fix GDBserver Aarch64 Linux regression > > Luis noticed that the recent changes to gdbserver to make it track > process and threads independently regressed a few gdb.multi/*.exp > tests for aarch64-linux. > > We started seeing the following internal error for > gdb.multi/multi-target-continue.exp for example: > > Starting program: binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue ^M > Error in re-setting breakpoint 2: Remote connection closed^M > ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.^M > A problem internal to GDB has been detected,^M > further debugging may prove unreliable. > > A backtrace looks like: > > #0 thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120 > #1 0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31 > #2 0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194 > #3 0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226 > #4 0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226 > #5 check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862 > #6 0x0000aaaaaaacc660 in read_inferior_memory (memaddr=, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93 > #7 0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071 > #8 gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048 > #9 0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307 > #10 handle_serial_event (err=, client_data=) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520 > #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700 > #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596 > #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237 > #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518 > #15 captured_main (argc=4, argv=) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998 > #16 0x0000aaaaaaab66dc in main (argc=, argv=) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084 > > This sequence of functions is invoked due to a series of conditions: > > 1 - The probe-based breakpoint mechanism failed (for some reason) so ... > > 2 - ... gdbserver has to know what type of architecture it is dealing > with so it can pick the right breakpoint kind, so it wants to > check if we have a 64-bit target. > > 3 - To determine the size of a register, we currently fetch the > current thread's register cache, and the current thread pointer > is now nullptr. > > In #3, the current thread is nullptr because gdb_read_memory clears it > on purpose, via set_desired_process, exactly to expose code relying on > the current thread when it shouldn't. It was always possible to end > up in this situation (when the current thread exits), but it was > harder to reproduce before. > > This commit fixes it by tweaking is_64bit_tdesc to look at the current > process's tdesc instead of the current thread's tdesc. > > Note that the thread's tdesc is itself filled from the process's > tdesc, so this should be equivalent: > > struct regcache * > get_thread_regcache (struct thread_info *thread, int fetch) > { > struct regcache *regcache; > > regcache = thread_regcache_data (thread); > > ... > if (regcache == NULL) > { > struct process_info *proc = get_thread_process (thread); > > gdb_assert (proc->tdesc != NULL); > > regcache = new_register_cache (proc->tdesc); > set_thread_regcache_data (thread, regcache); > } > ... > > Change-Id: Ibc809d7345e70a2f058b522bdc5cdbdca97e2cdc > --- > gdbserver/linux-aarch64-low.cc | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gdbserver/linux-aarch64-low.cc b/gdbserver/linux-aarch64-low.cc > index c924821c25c..d1e7acb7b4a 100644 > --- a/gdbserver/linux-aarch64-low.cc > +++ b/gdbserver/linux-aarch64-low.cc > @@ -191,9 +191,9 @@ struct arch_process_info > static int > is_64bit_tdesc (void) > { > - struct regcache *regcache = get_thread_regcache (current_thread, 0); > - > - return register_size (regcache->tdesc, 0) == 8; > + /* We may not have a current thread at this point, so go straight to > + the process's target description. */ > + return register_size (current_process ()->tdesc) == 8; Sorry, forgot to tell you I fixed a typo in the patch above before testing. It should be: return register_size (current_process ()->tdesc, 0) == 8;