From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2062.outbound.protection.outlook.com [40.107.22.62]) by sourceware.org (Postfix) with ESMTPS id A73C1385E447 for ; Tue, 5 Apr 2022 15:24:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A73C1385E447 Received: from DB6PR0202CA0012.eurprd02.prod.outlook.com (2603:10a6:4:29::22) by DBBPR08MB5962.eurprd08.prod.outlook.com (2603:10a6:10:202::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Tue, 5 Apr 2022 15:24:34 +0000 Received: from DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:29:cafe::25) by DB6PR0202CA0012.outlook.office365.com (2603:10a6:4:29::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31 via Frontend Transport; Tue, 5 Apr 2022 15:24:34 +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 DB5EUR03FT060.mail.protection.outlook.com (10.152.21.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19 via Frontend Transport; Tue, 5 Apr 2022 15:24:34 +0000 Received: ("Tessian outbound facaf1373bbd:v118"); Tue, 05 Apr 2022 15:24:34 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2c38016f57b7eb4d X-CR-MTA-TID: 64aa7808 Received: from 23cbe93fb479.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 59A4147D-CE2E-4FC1-8B71-E93C7E0F9C65.1; Tue, 05 Apr 2022 15:24:27 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 23cbe93fb479.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 05 Apr 2022 15:24:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GMJWtl6kZRh5hLQ/oFcwbc5/ZjKbl9vsMDiFFW0dQwL8L4n8LodyaUCmujngC04Xhs0Lng7ToBQVn/OcjjDnNOkZe1bcpE5lMBsiGlaRafkfXO5viEWrWGh9srnRjYWd5zv2MZVqORZeXFVlf58g/BOlaGoWlOWizOE2castE4WeZO4EoIy9Dw0QGxmk+WYfFVyIKyBa+jb6DZNUDDXnJzlLqlyy4W0WZDLn0izZeOcMITNBwUwB+a0/B/sfhsUTTK+Ws/8jZtnrGlATJEzj77Rb51seXeBDrVcVD/3fZW/GquJxrqygZQbibzRR3murj51JNmhJuKNmhIJKwJ/jeQ== 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=n35uoAgRdGgSli8c5a4d3NMreJO6MM3ntnwWLMg1Sm0=; b=cll7X1zba/cH7tEQ5arK4k9Z1zowDvtVr5Yd2aXznlrBucp709PbMwOGKYQb+oJ0WLbpcTWp/7voG8Y8OEppve26lq7Z9uETOzbmQtUxAeHOpPt0B5qO/ks4TIT4GbtSbo0S9C2QMoQM07i2iqzqFl5BgQEbFSp66WhZvqtpoUr3g8z3oKZGpkVS+bh6ZRF3PZRH16vfL+g6GT1tQr3dJ0N/w/DJ0VvAhybolsd5XilGrJT4g8+viA9gDvOVYs4A2vaVBhAlP10KUkvCby398zGuSNaZUThyWc6BhRvCwioSJ7ELlFvaukuMxSWV20bFhI++0JNk53pqJeFiqR4spA== 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 AS8PR08MB8037.eurprd08.prod.outlook.com (2603:10a6:20b:573::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.30; Tue, 5 Apr 2022 15:24:25 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::905f:29ee:d858:516e]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::905f:29ee:d858:516e%7]) with mapi id 15.20.5123.031; Tue, 5 Apr 2022 15:24:25 +0000 Message-ID: <2c2322c5-33fa-3d9a-c1e4-088a5969af32@arm.com> Date: Tue, 5 Apr 2022 16:24:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH, v2] Fix reverse stepping multiple contiguous PC ranges over the line table Content-Language: en-US To: will schmidt , gdb-patches@sourceware.org References: <7a429c919395db6ec4642803badca5dbb97bff66.camel@us.ibm.com> <20220331135246.7913-1-luis.machado@arm.com> <3d467cfa-1844-397c-931b-ffd832fa254f@arm.com> <553238d49ce5aae0e88a6ce0b7dd6afa96931bc6.camel@vnet.ibm.com> From: Luis Machado In-Reply-To: <553238d49ce5aae0e88a6ce0b7dd6afa96931bc6.camel@vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0483.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13a::8) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 31d591c9-981e-4762-90ae-08da17186388 X-MS-TrafficTypeDiagnostic: AS8PR08MB8037:EE_|DB5EUR03FT060:EE_|DBBPR08MB5962: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: MlCBmJBXSiijWQcaqM7hY7ILhvQT7EeVTa5YqbDEGHJb7Cz8lS6NgUMIM5dqIxAnTuxJayg+nd01ePNSFGDDFWGhkzgi2NOhSdHBpWaU+kHmwv5nayOpzRCIJ4v0dlQKYTjkThLkoor9Dde7VGfeAhsGoVkTc847iPLcYEAdjo9G6Gafqeik87zXuTXBGTC7WSoX8jowH9FVT0iIgHRnoWGAFRE4HEbqR1847jGqFGiBYUtZ/f6zHUdqd/0ef9dpSsTycfNarGb5QZHThFVMmWFWmURveKyBgV6AC3aU8NQQm90DljC8YPSCC7cIKMBCwfqgbTx8MuRVptakfN7G7MUDWPhzLtpXh2Qb0o0fMr0CdAOK8gCncZypWyJ15QogHMxX9hx+X3swVodA/QnVZVdVE9YhnW9WtfqU4MGUetsX3sZA9kq9G7cnMojkEMPkOo1CS3Byzt31UywL610JzRyazMFnfqGNPYoq5imjTtt6H5kFfVSaJmSuStPi3xsZdmy+vnEXxiTmsIqpPBbeoCepj6QwtGSsRwgkmRvBdkZXm0e7LZsC2IyIV5Wx7KLXcEBCnDSZFlZqXLxjybD873JtoCRno+EpQe0UNFkfokyPFCVibd0US8IcYYM0vWrZcS98V/g7/qFq1DQAmKY9EusD2hGaBcwsu8EmNYXcep1d/K7S9HkmQn/c3spVHRsSNl04Fy/PwEyswwjo9kZjPEhLdtB499gSkSL8vfGfiNZf5RCUyFzaPlY5Jrd9xoHQHjFuIHn2Bx8F76JVa14OFPDoofd8AamD9jPWx2kwBKkEoqz9JjZfvNVfnHp6QJ7i 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)(66946007)(2616005)(31686004)(86362001)(8676002)(36756003)(186003)(31696002)(5660300002)(66556008)(66476007)(38100700002)(316002)(26005)(53546011)(6666004)(6506007)(84970400001)(6512007)(2906002)(8936002)(508600001)(83380400001)(6486002)(44832011)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8037 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: DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 6a1d8b9c-8e79-4068-90a2-08da17185d66 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 07Ahx7+EILMBddUIpayqRsL21PWxVg+UrCk5Ccp0RRucD1YE1bZB6CHBJoxIAboYqWr6nWr5GAlQG4Lzd69ldtkydzUPHqq6lyLLjl4v+A0vTSlZJSzaZHnbP1P2jG3tshH5kTpMinSVzWKewFpKgD+dIEfAghHERHeWvSqY/PzXSCU0WuGpowdmzryBvJGk17kjCy4/XahALPI8bzpPGvag5oaJmj7fBWB9hz96/x2x4gjK1imJC0I2Al4y/5NM6TIGJqwyNf106/+2czfW4kQ12xz6gQjOTTw1G5pfHd8h5jGMitT+VlnGBEVtTPq90xwzgDUL2VYme5nJuy0InixiTLhi/2d8n8rv3csZIrjbTckwNmasQEMwOIpXtCrAphQoP4WhWW3PkEtEmqvpKw2Yq9j9UPF9TF4j+1QwshaPgeKwSWzy6BW6uZyoXtiDkI1xwWbeP3jWiFOW7R2fZmu/MhqLJ7BZiZjnmxAsSkHXTpt6Ah1CRTawPnT9ogR/QDm1NKBFW6B8DT5XcS0YgWUq/pF7BVzYZMW+1yM42cj8ffZoH6IFXzrxvL4uzj8AuhMyLsnJDI/YcHc7dMWJwfWquJdowZVOHOTiJwWB9ntzmFZNzy5dKQ7Tl947ak6ljGsPhwL6b4LrMwVVjbJb/GK8dof2hMs1UC3k30F5Slc/BZpl3O3m8BEzqPD9DaJ9lr8Vj2gRDS4FTRYPXvmRwHKd+0LIhHtge5iqXW/ZqyZzEEFNEt7DFShAy5E/1Q5zBznmtUdRVXLLjonJPN+TGuWp6b+SklDLgZkDIqrmbAg= 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)(40470700004)(46966006)(36840700001)(2616005)(83380400001)(31686004)(186003)(82310400005)(81166007)(36756003)(86362001)(6486002)(316002)(336012)(40460700003)(31696002)(26005)(70586007)(47076005)(2906002)(8676002)(84970400001)(508600001)(70206006)(356005)(5660300002)(8936002)(36860700001)(6506007)(6666004)(53546011)(6512007)(44832011)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2022 15:24:34.2738 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 31d591c9-981e-4762-90ae-08da17186388 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: DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5962 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY 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: Tue, 05 Apr 2022 15:24:38 -0000 On 4/5/22 16:15, will schmidt wrote: > On Tue, 2022-04-05 at 09:36 +0100, Luis Machado wrote: >> On 4/4/22 17:55, will schmidt wrote: >>> On Thu, 2022-03-31 at 14:52 +0100, Luis Machado via Gdb-patches >>> wrote: >>>> v2: >>>> - Check if both the line and symtab match for a particular line >>>> table entry. >>>> >>>> -- >>>> >>>> When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also >>>> spotted on >>>> the ppc backend), I noticed some failures in gdb.reverse/solib- >>>> precsave.exp >>>> and gdb.reverse/solib-reverse.exp. >>>> >>>> The failure happens around the following code: >>>> >>>> 38 b[1] = shr2(17); /* middle part two */ >>>> 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */ >>>> 42 shr1 ("message 1\n"); /* shr1 one */ >>>> >>>> Normal execution: >>>> >>>> - step from line 38 will land on line 40. >>>> - step from line 40 will land on line 42. >>>> >>>> Reverse execution: >>>> >>>> - step from line 42 will land on line 40. >>>> - step from line 40 will land on line 40. >>>> - step from line 40 will land on line 38. >>>> >>>> The problem here is that line 40 contains two contiguous but >>>> distinct >>>> PC ranges in the line table, like so: >>>> >>>> Line 40 - [0x7ec ~ 0x7f4] >>>> Line 40 - [0x7f4 ~ 0x7fc] >>> >>> >>> >>> >>>> I'm not particularly happy with how we go back in the ranges >>>> (using "pc - 1"). >>>> Feedback would be welcome. >>> >>> I suppose there could be a loop of some sort that iterates >>> backwards to >>> a valid line; though I'd think pc - 1 is sufficient? >>> >> >> Yes, it seems to do the job. >> >>>> Validated on aarch64-linux/Ubuntu 20.04/18.04. Carl Love has >>>> verified that it >>>> does fix a similar issue on ppc. >>>> >>>> Ubuntu 18.04 doesn't actually run into these failures because the >>>> compiler >>>> doesn't generate distinct PC ranges for the same line. >>>> >>>> I see similar failures on x86_64 in the gdb.reverse tests >>>> (gdb.reverse/step-reverse.exp and gdb.reverse/step-reverse.exp). >>>> Those are >>>> also fixed by this patch, although Carl's testcase doesn't fail >>>> for x86_64. >>>> >>>> There seems to be a corner case where a line table has only one >>>> instruction, >>>> and while stepping that doesn't take the same path through >>>> infrun. I think it >>>> needs some more investigation. Therefore this is a tentative >>>> patch for now. >>> >>> Are you (or Carl) continuing to pursue that edge case? >>> >> >> Not at the moment unfortunately. I know that this needs to be handled >> in >> the fallthrough of process_event_stop_test. Carl's test doesn't seem >> to >> fail for x86_64 (at least for me). We need to polish the testcase a >> bit >> more so that we can cover that corner case as well. >> >> Also, this is more of a RFC at this point. You'll notice some debug >> print statement in the patch. It would be nice to turn those into >> permanent debug prints, as this code doesn't seem to print too much >> detail about what it is doing. > > OK, > thanks. > > I did notice the debug printfs. Since they were actually using > the infrun_debug_printf helper, versus actual printf calls, I assumed > they were deliberate and meant for the long term. :-) > I wasn't going to > nit on the uppercase content of the debug printfs, I figure since they > are actually debug for special circumstances the debug was fine as > presented. :-) The upper case is so the text stands out from the rest of the debugging output. :-) > I'm generally a fan of adding more debug output. I think we should, in this case. Otherwise GDB will silently pick a different stepping range without making it clear why it did it.