From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from CAN01-YQB-obe.outbound.protection.outlook.com (mail-yqbcan01on2088.outbound.protection.outlook.com [40.107.116.88]) by sourceware.org (Postfix) with ESMTPS id 570613858404 for ; Wed, 2 Nov 2022 18:22:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 570613858404 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-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gNA6Byx7w8Q/x4Uh6+hPQWW6NO05929unFPiZrbyw2wvqYloCC9D3HiyJhX1Z6rTooytnD/TKc1L+oTJihx8CAP4pGjFK7fBdzRFT1nzhx3kICtLE4cZpRcrSC2nnnlxzfxIXFAzDhIi8C0o80lqq+tO7WtvgxGNgTIVmDViHjYXoKW/+kLCyRvlA0hcGWMJECpVZkxcfYfQO4SNA9a8f4tgzozqpFACs1Twl80Iwf9RfW0iVfTzzMI8EZRUKlFfVzRL6MDR3WAiMMK7tttoLkTfAQrlujbpXuqjQt2d7As2lb16dGuJk+KVz8VO1P3VMwFBcGxempVFYAOSUStJlA== 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=g+ZmmPGBCoDWDTumXgr9KChwFbhcJDyDOK98vFQU3Pk=; b=AT/MU1z2wA+qnQ+kmKTcpUFbTZvFpVAwjmYHdI0R9ODcZYh/PR3d+CVjXDwT148z0PPhWsyn9rsI6z1Jjm+HE/9q1p242F/eOXpoyR5dzfmzOcbziUi2R05nrWxo6n3rDc+NMxDN2xw+S82HvbM1SAuj9Sda9+gXLhFAIxblbq+Hd1EvMmOYEkoBeQw20QBLEIr/eJPqsDwA28sHL0A+bMvid43DRSgKh/Axk5U7oNe1/DFJZyjfobgZwOMX4YL9orc0R6ZEuruXqcWc6+O1TT5KkpwJB+k6IULj0nNXKBb9Wsrg6xbJ9q8euUOpK6URG1ElGgglSPgTjO6qR4cHdw== 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=g+ZmmPGBCoDWDTumXgr9KChwFbhcJDyDOK98vFQU3Pk=; b=XkUzLirkBb57C5n8+rM/DgOBgdjMew1wS2/MlfXQRlsMVdYzFC44PTb7cd1p1tQXt6N2ZCR4cQFC2K3cby04ZUXBvLAFq6ciiZrax5yMi+M9GxgzxMlY1CLIWzVz4XtOOt5TVT/uucnDJh7zNXotahi2dgtazQuOuUC6mnFdksVyShWGtxBB7ZWWNLWVs7pC/jENtiiB7/c9Ok6I9kASmMJuPqpWLbrqhcKjp1xTCy3AKxuCGK3U/UiAw5/EdrEKI7wvAMLCFSWWp/JwrXWVDsf7nPXCWnYKhemxvwXDXSiLyN4nATNNpWlQmAN7VQADlRaxah8xfEF8GrtbrMS6fA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:a::23) by YT3PR01MB5352.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:64::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.22; Wed, 2 Nov 2022 18:22:35 +0000 Received: from YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM ([fe80::2465:ab25:2168:32df]) by YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM ([fe80::2465:ab25:2168:32df%4]) with mapi id 15.20.5791.022; Wed, 2 Nov 2022 18:22:33 +0000 Message-ID: <9f98d3c6-1a56-e66a-e987-c0ece9a3d2b6@efficios.com> Date: Wed, 2 Nov 2022 14:22:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH, v2] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr Content-Language: fr To: Luis Machado , Simon Marchi , gdb-patches@sourceware.org References: <20221026084100.28009-1-luis.machado@arm.com> <20221102143341.2807182-1-luis.machado@arm.com> <376afc60-6910-56b2-bad5-b9850d2999b5@simark.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: YQBPR0101CA0045.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:1::22) To YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:a::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT1PR01MB2828:EE_|YT3PR01MB5352:EE_ X-MS-Office365-Filtering-Correlation-Id: 59672ef1-18ab-4276-480e-08dabcff361a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jlhFjQn8L9J030xmYNkb83MNEJ1KDntjoG/D6Rw+uJzCtIHMOQ5+amixwAeTzWvodfj7QJ1HlRcbeSQHtAF09kunvYHxj//G3LnneWQRNG2P5jhYH6eIPBmiqaSqCHdvvAhgaDYodB7AYconbs6yBy/9D28PY7L87IPV6C6cLntJOCeExcPgfoNElRudm7cC7rTlbefcCG8GDp7WxJC23O5PgTFIfG/DIfL8TTcRX5z790bUEPtBFnH6TZJjPXkMZCiCS/XElJTXMc5yf46YJk2YFxOTsAPxjqwytmBQfeaFR1dpZ96XGgjfAXUDYu0DN5s5307jPRRfThkd7YcD+tg27Jpo8htfSMMZnR6JjV3z3tu+jvcJhJeUYIrIXtFLsQcXDhhLfEygDJef9mXP8yAWQiv7RROygGYMxbTF0c+GgtINT0sHpfcfNMgf11ntsonLRAOFlIDA1JbQZ08aWhT6GdhQme3wSaeyeW+oQlBf0TICSbc1eRIaZKeD5VRaXuPWLsjoA9hFB1BgqBcSOFG3KW8yu+0ZUanw4/35NdtIE4y/KDD/BwVUPz2p1QfooecHW6MhAXn7LDoEauR90ZdbvFQo2Ui++MlixopGUMrfi7AI7SbT1Wi+yJap0JNuOJ2nTJhMEzjki6l2/oSdyOL4umVeFWjP+23k7WAACs+JAiEBnD/2p0E3YwFZPCdPpJqL9apu5l3XHcmZvbFkpVaaOh5neZq9RfC5nxCELowvWAeJAin+cSP5UY20vgfT3KHkFjZrvVRdz48KDRLorBnz/arVL+qAmcbFO8ALRPiOxImt3XIrGLYC2vhT4oWQ X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(366004)(396003)(39830400003)(376002)(346002)(136003)(451199015)(66946007)(8676002)(66476007)(66556008)(316002)(2906002)(41300700001)(8936002)(44832011)(5660300002)(53546011)(6506007)(6512007)(26005)(83380400001)(478600001)(2616005)(186003)(6486002)(966005)(110136005)(31696002)(31686004)(38100700002)(36756003)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b01LZ0FhSDJrdm4vaFpubmxDT2dSUDRmWXlnV2J6bG40MWVVdDIzVjEySUM4?= =?utf-8?B?V1RyL1pJc09SY3M5NzJSUldmWFFrbEJQcEV3ZFQ5S1BvaUkwWUl5dmhickJR?= =?utf-8?B?YVVUWUEvZU5aZzVhc0UwWVQxcHowVnZSTG1JaDg3THJWL1VyM2tHaUtmWHNC?= =?utf-8?B?QVJtd3phMkc0VFJEMXhjR2p5OVIxU001d2o4cWpuWEtNYTlqQ0tLU3QwSUJk?= =?utf-8?B?WHNxYld2MDFsbnFPMk1Bdzc3eFJtTkl2d2FNbXRJUFNGVGhsNWZOa3ZJZGh4?= =?utf-8?B?TDRoOCtKaVNIb0Z6RjhZOWtlSjNaMk1Qa0NJL3VTRG1FQnJ0RE1tQ1RrelVy?= =?utf-8?B?aEVuUWxuU0QxMzRzOUltM3VMUnJCUlNZL09tMEptWU1heDFWUkNmYVVvaXNH?= =?utf-8?B?c202QUY3bktZVVlMMmJUQk9zUWVWeVd1bkxkRlNSQktvSGVLSFQ4a1djTGFY?= =?utf-8?B?amJZTStKVy90RmtoeU5wOExPTTZWKzJ5WW44dHFiUkxxNUR6Y09yOVpSV2pQ?= =?utf-8?B?V1RRL0xtcU1vRER4eEZIL2VwZEdkeWhyQ3B1N2taQW9pdDBVakw0MjlVNnZF?= =?utf-8?B?RSsveTQvREFYZlNrVDJ2N3E0blhHUXR2b2srN3ZPUmpzbXpUTW9YYkRwQko3?= =?utf-8?B?amR4RXBkcHV5Z1Q3TXJHTnBYTVFUa0paK2UwdldzQWhMeTFJdStPR0pURVlT?= =?utf-8?B?YityalRqcXFGZ0hrYVdVeVM0NFA5WE56NXlydkxmU2J2U2cwOTM2dEFvQnFu?= =?utf-8?B?Um9ML2tKa1VoUDZzVU9JU2Q4WklMMWpIcjJZZUU1bHlXampLNHl6a2VGbDhO?= =?utf-8?B?cStsZVZIQWhXMlRiZnM1RjRvUGgySGxHbXZqdU1yeFJMMC9uQlhIUDYwenNP?= =?utf-8?B?S0NoajQ1S3ZYdUhEU2RReFBWQWVqTDFZdHFRTXQrWGxBdXV6elVEakp3MkN0?= =?utf-8?B?QmxJUlErbE9RK0xFc29RZEJGUU00aXV5SWZtazF5VkpiVXA0WVVCcUU1a1RJ?= =?utf-8?B?MkwwV21YcFpvUnFQVTJPUTVGV2hNQlVIVXBOcWk2RnNvWFBVV0RNNkR2WjBv?= =?utf-8?B?TU45UUYydFhuVm05OUE1bnFvaU5ZVStuS3VqOWIwQTFWaDYzSnFRdEJ1WnlN?= =?utf-8?B?Uyt6ckNSa0wyRmpuNnhwL0hpYjhEbTgrSjJvN3RlR0V1Q2ZuSGx3LzBhNnlN?= =?utf-8?B?QisvWE96bXFndlduV2tGcW9McDlqNjRNL0pFRytMMTZZNU9kQUlxMXAzRlBQ?= =?utf-8?B?emgzYXNoR3J0bU4rQVhGN3NuUmQ3ZjgvQ2h3RXF4eUNJdTk3UFA3cFBZeDV4?= =?utf-8?B?OUUxTkxLRVQ1Y3RZVDZYYTgweFJ0SlpxTWQvZGh2TVh6SVJtbzUxaUZHTUc5?= =?utf-8?B?bVhMbzRBNnpod2FzK3J5NUZkZ2VWd0pYUnJnNEZyUlovNTRtWjNLcTI2Ymd5?= =?utf-8?B?V3VFaU1PWjFIVTdzYnRYK3FSTVVYcFhBQnY2L3F1enNRYVBBbThBVUZOYXl1?= =?utf-8?B?VWZWZmYrZWF6Si91RmxYWVpXWHRZTGV4Q0JCUlJPNjc3cERwYVFxNnZ2VzFq?= =?utf-8?B?T3VEMW9tdEhjY1NSRFdjSkZRcUk0THpPZTNuUjJ1S3dlV1JPMVRQUjFYOHl2?= =?utf-8?B?cEp6ZlBJVi9FWkhtdFA5aVFUWU5OQkpoTVFLRnN3SUdMci82UHlYSDJKQzNQ?= =?utf-8?B?S2FzblB4eFRjYnRleDJZSmZmdzZjVjB6RGEyeExFTzRtUkhoZW05aFhjbTA2?= =?utf-8?B?dEhBSUFsT2M2VDFMT2cxRm4ydm45RE1nV2FDZHNReFd4aU8xTmRZRFB6UHlW?= =?utf-8?B?WFZVOUFQUG4yb2VDOWtXMWxXNGhmS25ITzA2c0paclRCamh6UmFTVjJxNmM2?= =?utf-8?B?S3lFQk02Wnc5WnhOVFJsQ2x2NE50QjJrSkJ2eTRuWjVaRVVNbHZiYmxvVmVh?= =?utf-8?B?aUdNTVpZTHpwZ1RBbVNXRXJEQWZoNGh5VCtBWnNmZVd5NXQ4eDZwaFhMSDZY?= =?utf-8?B?a2lUUHprbW9mSm1CVVQzaGhUQklVelZMankvQ2NQQ093M2o2NCszalJYT2JL?= =?utf-8?B?ZjdhRFc4UXAxaDVuZlEyemZlc05oM1hJSnJBbGlpRDZZUW5QUHVYK1p1NnJ3?= =?utf-8?Q?j9K0wkQQwi7F9xLsnHlh5BEcO?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59672ef1-18ab-4276-480e-08dabcff361a X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2022 18:22:33.8127 (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: gaDSuzjP0UaaINy9mLKBnCanSRYdhU+wwc08hUojBeVc44yennlB4nAjhlL+UMUiFWNFEGKyuM5fxfIpwN4hlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB5352 X-Spam-Status: No, score=-3038.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP 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 11/2/22 14:06, Luis Machado wrote: > On 11/2/22 17:44, Simon Marchi wrote: >> On 11/2/22 10:33, Luis Machado via Gdb-patches wrote: >>> v2: Add try/catch block >>> >>> Investigating PR29272, it was mentioned a particular test used to work on >>> GDB 10, but it started failing with GDB 11 onwards. I tracked it down to >>> some displaced stepping improvements on commit >>> 187b041e2514827b9d86190ed2471c4c7a352874. >>> >>> In particular, one of the corner cases using copy_insn_closure_by_addr got >>> silently broken. It is hard to spot because it doesn't have any good tests >>> for it, and the situation is quite specific to the Arm target. >>> >>> Essentially, the change from the displaced stepping improvements made it so >>> we could still invoke copy_insn_closure_by_addr correctly to return the >>> pointer to a copy_insn_closure, but it always returned nullptr due to >>> the order of the statements in displaced_step_buffer::prepare. >>> >>> The way it is now, we first write the address of the displaced step buffer >>> to PC and then save the copy_insn_closure pointer. >>> >>> The problem is that writing to PC for the Arm target requires figuring >>> out if the new PC is thumb mode or not. >>> >>> With no copy_insn_closure data, the logic to determine the thumb mode >>> during displaced stepping doesn't work, and gives random results that >>> are difficult to track (SIGILL, SIGSEGV etc). >>> >>> Fix this by reordering the PC write in displaced_step_buffer::prepare >>> and, for safety, add an assertion to >>> displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right >>> when it sees this invalid situation. If this gets broken again in the >>> future, it will be easier to spot. >>> >>> Guard the code in a try/catch block to handle the case where we can't >>> write the PC, so as to not leave partial state in the displaced step >>> machinery. >>> >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272 >>> --- >>>   gdb/displaced-stepping.c | 26 +++++++++++++++++++++++--- >>>   1 file changed, 23 insertions(+), 3 deletions(-) >>> >>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c >>> index eac2c5dab94..3b5376cf31b 100644 >>> --- a/gdb/displaced-stepping.c >>> +++ b/gdb/displaced-stepping.c >>> @@ -139,15 +139,31 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) >>>         return DISPLACED_STEP_PREPARE_STATUS_CANT; >>>       } >>>   -  /* Resume execution at the copy.  */ >>> -  regcache_write_pc (regcache, buffer->addr); >>> - >>>     /* This marks the buffer as being in use.  */ >>>     buffer->current_thread = thread; >>>       /* Save this, now that we know everything went fine.  */ >>>     buffer->copy_insn_closure = std::move (copy_insn_closure); >>>   +  /* Adjust the PC so it points to the displaced step buffer address that will >>> +     be used.  This needs to be done after we save the copy_insn_closure, as >>> +     some architectures (Arm, for one) need that information so they can adjust >>> +     other data as needed.  In particular, Arm needs to know if the instruction >>> +     being executed in the displaced step buffer is thumb or not.  Without that >>> +     information, things will be very wrong in a random way.  */ >>> +  try >>> +    { >>> +      regcache_write_pc (regcache, buffer->addr); >>> +    } >>> +  catch (const gdb_exception_error &except) >>> +    { >>> +      /* Reset the displaced step buffer state if we failed to write PC. >>> +     Otherwise we will prevent this buffer from being used, as it will >>> +     always have a thread in buffer->current_thread.  */ >>> +      buffer->current_thread = nullptr; >>> +      copy_insn_closure = std::move (buffer->copy_insn_closure); >> >> The intention would be clearer by just doing: >> >>    buffer->copy_insn_closure.reset () >> >>> +      return DISPLACED_STEP_PREPARE_STATUS_CANT; >> >> I think we should just let the exception escape, >> DISPLACED_STEP_PREPARE_STATUS_CANT isn't meant to convey an error. > > Wouldn't letting it escape completely abort the single-stepping operation? I was expecting a return of > DISPLACED_STEP_PREPARE_STATUS_CANT to have a fallback of stepping in-place. Isn't that the case? Yeah, but I think that's what we want. Failing to write the PC is an "abort mission" kind of failure, IMO. Something is very broken. DISPLACED_STEP_PREPARE_STATUS_CANT is not equivalent to an errorp, it's "we have successfully analyzed the instruction and concluded it can't be displaced-step". If we wanted to return a status code, I would suggest to introduce a new one (e.g. DISPLACED_STEP_PREPARE_STATUS_ERROR). But I think the exception is fine, this is how other kinds of failure that happen when resuming are reported, like when we fail to insert breakpoints. We arguably are not very good at handling those gracefully, but that's the problem of this code here. Simon