From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80048.outbound.protection.outlook.com [40.107.8.48]) by sourceware.org (Postfix) with ESMTPS id 0CCDB385AE59 for ; Thu, 9 Jun 2022 09:14:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0CCDB385AE59 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=EsGgle7EcKdf+TtPehm0G5ppvJzO6bXKBBryld0MksKWifOj4IelYdUKMzR3zV3e/wGdQUncwyH9yHlWNRuzDauGPlSWzRVFbdQtSX0j78V0hJPMsp9Le4zmOv43WugyNPbO4QQXhA8B0JlDZr6pxI2P26Rqya7ps7drX1J7c0ZED+wpwqLC4Lo8fGGDlJKr/YdkYAsW1QjOp6HmGCvVA9WVnqgpt1r1tp1ujtIaVZXOxxUy5c2a/rAdSyzO9PfYcM9ivnjT1EheKtY6qbCJnXctmBgSZThTvWsf9xFvolcFDxc2M9RLis9hGzY3NKkoYb4K2jL6p1ywQGvYhISdGg== 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=9CkCy9GExFRqM/5yWYt5Ahxh30WSCgEDJc2XnK9Da/0=; b=ZIx3czAts1fEp9PVWwLnjKiVZjlTqRtk5QFUu0B041rdxOZz3zjO6Jlqexk7VW7cVwDySduKSilc3qaF6rxQZFTrqrYXtp9GE7Cnp/lGuzO3b3udBm0H4q6tU1VnQC0hrD5meZkNn23bSKaft4npGTiRHSKPDmH605dIDLR7KuTKcMSbU5pgtUNBJd1GaUu71hQrafOoA++DIaqLkv0k0T/En8EZ9n86OlNGd62cgbpzleMsMSJw59+TGnL6cbkRX9nz4gj0o6DwEyucNh/qQJOIkhVE/4M+DJrBBeGg3h8CNEweaJIsoIjtaO+QqvF7/Q+HgzeEil8xbiwFD0PHNg== 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 AS9PR06CA0230.eurprd06.prod.outlook.com (2603:10a6:20b:45e::26) by AM6PR08MB3781.eurprd08.prod.outlook.com (2603:10a6:20b:8b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.14; Thu, 9 Jun 2022 09:14:00 +0000 Received: from VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:45e:cafe::5b) by AS9PR06CA0230.outlook.office365.com (2603:10a6:20b:45e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.13 via Frontend Transport; Thu, 9 Jun 2022 09:14:00 +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 VE1EUR03FT010.mail.protection.outlook.com (10.152.18.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12 via Frontend Transport; Thu, 9 Jun 2022 09:13:59 +0000 Received: ("Tessian outbound 4ab5a053767b:v120"); Thu, 09 Jun 2022 09:13:59 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a186207f092a5e3f X-CR-MTA-TID: 64aa7808 Received: from 06a1a9724eef.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2E8F765D-8EB4-4618-894C-A2A8595A4C87.1; Thu, 09 Jun 2022 09:13:51 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 06a1a9724eef.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Jun 2022 09:13:51 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=URgtyhw3ormIKPPLs3Cfo1zqKy3aoqmF0+s+Zw+cpE+ufqOh7Bpou0d4/3+JNjWdjyiugUa4B/RyqIjMSqowutuLB10v7zyZM6n5jGWju+LQRxzQwFZX6jeLTagQK5qeCWy7+wM+9C4pDOoort97uxhpVaD7huO3nDyjsTVQ+D/fI0QhBk0NUD/iPBzrj2ieCV7PG6chE0NJgcZieOQr3X7fxXfEo78aK1Iczxh7/pcE3+hINCu0KRToofxG/KkOx/E58AqNUiCjwaZMChTsGh1KHmFZdzYPeXzGJWYB+Cc+UtPnyNfa6/mP3wmnL336hMmJJ6m6/pCcYBJgc+3Faw== 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=9CkCy9GExFRqM/5yWYt5Ahxh30WSCgEDJc2XnK9Da/0=; b=BEdvMJySWrpRF5EbYuxLIOzQN0XZBKfYzFgEUIQqs7QHy1rZPYUaVh+7VGWHZRScIToXasF9ok0Tql3R73219LXxqh37wflNIMYuahjItVF/xnpEtSMvZM+7Hq3qxzXH8UB+wEajhqfjWKbQKQiLdvRLGjDR2xFbUNMnVM+33rT3O1eBRUNIIuT74bdQLf/TsL6U6KMXxYe1pk3Cv1FOjoj65krP6jxAvN9qq/QdB7Vasm+AppzzrBRXGDGbTnsL2CFWo+L/64AP+SZX5hAPzfdBrqUahoDUsR/nMVkWK/T1OEvVPCCqq7MK18kUtHigJuaecBhhxTaqi995RbZHNA== 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 DB7PR08MB3674.eurprd08.prod.outlook.com (2603:10a6:10:4a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.13; Thu, 9 Jun 2022 09:13:49 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::d9c0:539c:a641:5735]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::d9c0:539c:a641:5735%2]) with mapi id 15.20.5332.013; Thu, 9 Jun 2022 09:13:48 +0000 Message-ID: <087672fa-c1ec-d288-38d7-82ff41002f31@arm.com> Date: Thu, 9 Jun 2022 10:13:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH,v5] Fix reverse stepping multiple contiguous PC ranges over the line table Content-Language: en-US To: will schmidt , Carl Love , Bruno Larsen , gdb-patches@sourceware.org Cc: rogealve@br.ibm.com References: <20220506085506.9184-1-luis.machado@arm.com> <9e420536-01e0-7192-d585-747c52fdf4d5@redhat.com> <65abc453edc9d73df97a8630503420ebf8c5747b.camel@us.ibm.com> <971526aef8d957f678d9a8b10bfa2e41c4ea41c1.camel@vnet.ibm.com> From: Luis Machado In-Reply-To: <971526aef8d957f678d9a8b10bfa2e41c4ea41c1.camel@vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0148.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::9) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 288345c5-6cb9-49d3-2710-08da49f863ba X-MS-TrafficTypeDiagnostic: DB7PR08MB3674:EE_|VE1EUR03FT010:EE_|AM6PR08MB3781: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: ykN3oobikRvolFNdXSDVB0qWWDWnBRjYe4g4uJwI7oY0xT1EGOhTSb+AIUGftM66VAgPrcKo76g2JlFEk8PcSeO+UUFsDigtKBbYKzdQ3pPOJQel2/yGfV9EAFdJOSGcTy0ZgW8K33CUAtmJuM+naDokH0ahW4uU8alwxseJvv+T35/R93Oq5lWEuQ8dRe7diQQSdKJomKHJLmPyi6XuKm/l9OtBCdNOeZCOrKpHMxJ/6CE4p5DKJA/qfkdain2VsEi88afmu1kXuMNEBgH8SeJKaVymDZx79CWwEy+Kea0t49sc28KLCmtSjoCWDBIuDftLWwZERUn+Z8TvkvRXZrZl62QO+Cy3IrL8LYfk7gkStBrfG0BHN8293CWzhh9HbJRkYRM9fVw4G0Q1Mjz/ycMLF+L7WjFHp8vvNo52uKWFyv0QuZjGJleco9vKHMQeuSA+qkZX9DRQlhK95Hh+G2oan4Bm1jYpTbaavt14hN7sJ3x73htWqze5W+eT/1w65OUNr31pGGy+oDjRqvLmVaRj3dQfWOlkhNZGJwZZZCFeBPcd2ZgMMClad6Zp38J+YGg8vqTxdiE+hp5p60Dcn1ovOkmxdTkuKRtBmaEeo3HRxvgw+D6LkKgpdqHTAvrYJ8ZKD3KMu7yH9KMNNHO5XykUMXw8jwY6nNeiLI1Rs/4YIvOthi1yEUUA/qRVOaySrLE4owLC3Qiu1c+ZjO938IX7W4BW7WAvAiF+OWoW79mDJrEejX2AIiKDOkHjPkOpBiJyfPhC8TAgehJJRgbXDG7XFbpdDUAQVi0FuELkBpcVdn16gFUw63PclTrCr9ceSi5uM/TWi+LKqYsRzL9na92Sg7r31GGDP0GY1eeZFECaHIUDkQQildg/Bzw52e9g 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)(83380400001)(36756003)(38100700002)(66476007)(8676002)(31686004)(66556008)(110136005)(4326008)(86362001)(316002)(31696002)(66946007)(26005)(30864003)(2906002)(186003)(508600001)(2616005)(5660300002)(8936002)(966005)(84970400001)(6506007)(53546011)(6486002)(6512007)(44832011)(2004002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3674 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: VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: a725149b-0839-45ee-1af0-08da49f85cfc X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YN8GMUC/X1lc4D6c1BAVo/6niZfSi9wiv8DH/zfWtryYkhWpZveptehopUYlp6tLPixfTxoBnK/i04DnIoMIc6xsm4V2EyeEfUJu8jCsizWCCkgPpCE4OZ6UZp1/9VGhOnbdCKRtzhzm21RhEhXgq+rReI3I7SmGREd9vOMTVB2VF10Sf2HNmzcbSI04Ll00gqMaoFJCL3hEfIMaA7x8rUe0Tl+Sf9IjC8ICHj4vMuE/tcedil7xUq6JFTBNbAljyeeJBOx6Nd4Hu+VcECIKPvUSpqfuA40JRqek9kW9aN44bTfcMY0mIzOLv51hsyeqvk1MUp/jAth41EwsToyyMvJLlJi0B2vNqm58us1rHJCk5llohXHVWg2NUoGuSLQF/lWkX8oxDhB8hx9dc+KXN/3hgMtXavc3/3oyEOqbqPpyTiaqWot9s0vIMuW3zO9i4w6yDSNAJxENPfCDiTTlxO4d8yFnyIoFAChWKz9eZZ/CPGCnF+Fnr218u7RYTqpZfKp+NFgPz9ss/LDbmFTGFX4cai93OwB0W5T8AJz2M8MY+DXk22PULSCS2ACehlEXd5kGx/2PkVNzMHi4fPFJxMphx4VxDYi/4kXkCzPF9/xFkQsEVAYU/CavBSkOpVbh3HYcjLsisM6LVBFJ+P0y8aXooTgHg60j8E+3pLAqIKCKq8xvo06A9msPxyaYroa6tT/aGlAu2bxhqtKDSJS9JLqbN4DpfpMmFkSFIKXE2TMUxNOoBfJ+mb8NS7DmOs9GII1dq+gXj/2o302Dxddr9XMwURyjaYu+JaVsLiqp/vK8TWo3RVxgyk1TQdEVFj5O92I8x1AiJu9B4ZOCHIFLTTHBom51HJmY+uVkcX6BHI4= 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)(40470700004)(46966006)(70206006)(2906002)(2616005)(31696002)(26005)(316002)(31686004)(6506007)(82310400005)(966005)(40460700003)(47076005)(6512007)(36756003)(30864003)(70586007)(53546011)(5660300002)(36860700001)(8676002)(336012)(186003)(4326008)(81166007)(110136005)(86362001)(6486002)(83380400001)(356005)(508600001)(84970400001)(44832011)(8936002)(2004002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2022 09:13:59.8801 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 288345c5-6cb9-49d3-2710-08da49f863ba 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: VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3781 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 09 Jun 2022 09:14:16 -0000 Hi Will, On 6/7/22 18:11, will schmidt wrote: > On Fri, 2022-05-06 at 09:48 -0700, Carl Love wrote: >> Bruno, GDB maintainers: >> >> The patch has been updated per the comments on the testcase from >> Bruno. >> >> The patch was retested on Power 10 to ensure the test still works >> correctly. >> >> Please let us know if there are any additional comments or if the >> patch is ready to commit. We thank you for your help with this patch. >> >> > > Assorted nits below, but unless my comments reveal something, LGTM. > > > > >> >> Carl Love >> -------------------------------------------------------- >> Fix reverse stepping multiple contiguous PC ranges over the line >> table >> >> v5: >> - Updated test case comments on the purpose of the test. >> - Add test to check system supports record-replay. >> - Removed now unnecessary reord test when activating record. > > > s/reord/record/ :-) > >> v4: >> - Updated testcase to make it a bit longer so it can exercise >> reverse-stepping >> multiple times. >> - Cleaned up debugging prints. >> >> v3: >> - Updated testcase. The format for writing the DWARF program body in >> the >> testcase expect file changed. >> See commit gdb/testsuite/dwarf: simplify line number program syntax >> (commit d4c4a2298cad06ca71cfef725f5248f68205f0be) >> >> 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] > > > Curious, what incantation is used to collect the PC range info? > > You can use the maintenance info line-table. >> The two distinct ranges are generated because GCC started outputting >> source >> column information, which GDB doesn't take into account at the >> moment. > > > Not critical for this, but is there a general sense for when GCC > started generating the source column info? > > A couple commits, from these patches here: https://gcc.gnu.org/pipermail/gcc-patches/2017-February/469643.html https://gcc.gnu.org/pipermail/gcc-patches/2017-February/469644.html >> When stepping forward from line 40, we skip both of these ranges and >> land on >> line 42. When stepping backward from line 42, we stop at the start PC >> of the >> second (or first, going backwards) range of line 40. >> >> This happens because we have this check in >> infrun.c:process_event_stop_test: >> >> /* When stepping backward, stop at beginning of line range >> (unless it's the function entry point, in which case >> keep going back to the call point). */ >> CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); >> if (stop_pc == ecs->event_thread->control.step_range_start >> && stop_pc != ecs->stop_func_start >> && execution_direction == EXEC_REVERSE) >> end_stepping_range (ecs); >> else >> keep_going (ecs); >> >> Since we've reached ecs->event_thread->control.step_range_start, we >> stop >> stepping backwards. >> >> The right thing to do is to look for adjacent PC ranges for the same >> line, >> until we notice a line change. Then we take that as the start PC of >> the >> range. >> >> Another solution I thought about is to merge the contiguous ranges >> when >> we are reading the line tables. Though I'm not sure if we really want >> to process >> that data as opposed to keeping it as the compiler created, and then >> working >> around that. >> >> In any case, the following patch addresses this problem. >> >> Validated on aarch64-linux and x86_64/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. >> >> The included testcase (based on a test Carl wrote) exercises this >> problem for >> Arm, ppc and x86. It shows full passes with the patch applied. >> >> Co-authored-by: Carl Love < >> cel@us.ibm.com >>> > > >> --- >> gdb/infrun.c | 22 ++- >> gdb/symtab.c | 49 ++++++ >> gdb/symtab.h | 16 ++ >> gdb/testsuite/gdb.reverse/map-to-same-line.c | 55 +++++++ >> .../gdb.reverse/map-to-same-line.exp | 141 >> ++++++++++++++++++ >> 5 files changed, 282 insertions(+), 1 deletion(-) >> create mode 100644 gdb/testsuite/gdb.reverse/map-to-same-line.c >> create mode 100644 gdb/testsuite/gdb.reverse/map-to-same-line.exp >> >> diff --git a/gdb/infrun.c b/gdb/infrun.c >> index 6e5853ef42a..82c28961aeb 100644 >> --- a/gdb/infrun.c >> +++ b/gdb/infrun.c >> @@ -6955,11 +6955,31 @@ if (ecs->event_thread- >>> control.proceed_to_finish >> have software watchpoints). */ >> ecs->event_thread->control.may_range_step = 1; >> >> + /* When we are stepping inside a particular line range, in >> reverse, > > Nit: Could be rephrased as "When we are reverse-stepping inside a > particular line range" > > I agree that looks better in isolation. But if you check the code, you'll notice it seems to favor "in reverse". I just went with the current "standard". I don't have a strong opinion for either of those. >> + and we are sitting at the first address of that range, we need >> to >> + check if this address also shows up in another line range as >> the >> + end address. >> + >> + If so, we need to check what line such a step range points to. >> + If it points to the same line as the current step range, that >> + means we need to keep going in order to reach the first >> address >> + of the line range. We repeat this until we eventually get to >> the >> + first address of a particular line we're stepping through. */ >> + CORE_ADDR range_start = ecs->event_thread- >>> control.step_range_start; >> + if (execution_direction == EXEC_REVERSE) >> + { >> + gdb::optional real_range_start >> + = find_line_range_start (ecs->event_thread->stop_pc ()); >> + >> + if (real_range_start.has_value ()) >> + range_start = *real_range_start; >> + } >> + >> /* When stepping backward, stop at beginning of line range >> (unless it's the function entry point, in which case >> keep going back to the call point). */ >> CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); >> - if (stop_pc == ecs->event_thread->control.step_range_start >> + if (stop_pc == range_start >> && stop_pc != ecs->stop_func_start >> && execution_direction == EXEC_REVERSE) >> end_stepping_range (ecs); > > ok > > > >> diff --git a/gdb/symtab.c b/gdb/symtab.c >> index 4b33d6c91af..de4cb5dd0eb 100644 >> --- a/gdb/symtab.c >> +++ b/gdb/symtab.c >> @@ -3433,6 +3433,55 @@ find_pc_line (CORE_ADDR pc, int notcurrent) >> return sal; >> } >> >> +/* Compare two symtab_and_line entries. Return true if both have >> + the same line number and the same symtab pointer. That means we >> + are dealing with two entries from the same line and from the same >> + source file. >> + >> + Return false otherwise. */ >> + >> +static bool >> +sal_line_symtab_matches_p (const symtab_and_line &sal1, >> + const symtab_and_line &sal2) >> +{ >> + return (sal1.line == sal2.line && sal1.symtab == sal2.symtab); >> +} > > ok > > >> + >> +/* See symtah.h. */ >> + >> +gdb::optional >> +find_line_range_start (CORE_ADDR pc) >> +{ >> + struct symtab_and_line current_sal = find_pc_line (pc, 0); >> + >> + if (current_sal.line == 0) >> + return {}; > > I assume our lines start at 1 so this will never false positive? > Right, as documented in gdb/symtab.h: /* Line number. Line numbers start at 1 and proceed through symtab->nlines. 0 is never a valid line number; it is used to indicate that line number information is not available. */ int line = 0; >> + >> + struct symtab_and_line prev_sal = find_pc_line (current_sal.pc - >> 1, 0); >> + >> + /* If the previous entry is for a different line, that means we >> are already >> + at the entry with the start PC for this line. */ >> + if (!sal_line_symtab_matches_p (prev_sal, current_sal)) >> + return current_sal.pc; > > ok > > >> + >> + /* Otherwise, keep looking for entries for the same line but with >> + smaller PC's. */ >> + bool done = false; >> + CORE_ADDR prev_pc; >> + while (!done) >> + { >> + prev_pc = prev_sal.pc; >> + >> + prev_sal = find_pc_line (prev_pc - 1, 0); >> + >> + /* Did we notice a line change? If so, we are done with the >> search. */ >> + if (!sal_line_symtab_matches_p (prev_sal, current_sal)) >> + done = true; >> + } >> + >> + return prev_pc; > > ok > >> +} >> + >> /* See symtab.h. */ >> >> struct symtab * >> diff --git a/gdb/symtab.h b/gdb/symtab.h >> index b1cf84f756f..226fe8803db 100644 >> --- a/gdb/symtab.h >> +++ b/gdb/symtab.h >> @@ -2285,6 +2285,22 @@ extern struct symtab_and_line find_pc_line >> (CORE_ADDR, int); >> extern struct symtab_and_line find_pc_sect_line (CORE_ADDR, >> struct obj_section *, >> int); >> >> +/* Given PC, and assuming it is part of a range of addresses that is >> part of a >> + line, go back through the linetable and find the starting PC of >> that >> + line. >> + >> + For example, suppose we have 3 PC ranges for line X: >> + >> + Line X - [0x0 - 0x8] >> + Line X - [0x8 - 0x10] >> + Line X - [0x10 - 0x18] >> + >> + If we call the function with PC == 0x14, we want to return 0x0, >> as that is >> + the starting PC of line X, and the ranges are contiguous. >> +*/ > > ok > >> + >> +extern gdb::optional find_line_range_start (CORE_ADDR >> pc); >> + >> /* Wrapper around find_pc_line to just return the symtab. */ >> >> extern struct symtab *find_pc_line_symtab (CORE_ADDR); >> diff --git a/gdb/testsuite/gdb.reverse/map-to-same-line.c >> b/gdb/testsuite/gdb.reverse/map-to-same-line.c >> new file mode 100644 >> index 00000000000..dd9f9f8a400 >> --- /dev/null >> +++ b/gdb/testsuite/gdb.reverse/map-to-same-line.c >> @@ -0,0 +1,55 @@ >> +/* Copyright 2022 Free Software Foundation, Inc. >> + >> + This program is free software; you can redistribute it and/or >> modify >> + it under the terms of the GNU General Public License as published >> by >> + the Free Software Foundation; either version 3 of the License, or >> + (at your option) any later version. >> + >> + This program is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + GNU General Public License for more details. >> + >> + You should have received a copy of the GNU General Public License >> + along with this program. If not, see < >> http://www.gnu.org/licenses/ >> >. */ >> + > > This URL will need to be fixed up. Likely a side effect of the IBM > email infrastructure that does not exist in the patch itself. :-) > > I have a local copy where this isn't a problem. Pesky e-mail servers. > >> +/* The purpose of this test is to create a DWARF line table that >> contains two >> + or more entries for the same line. When stepping (forwards or >> backwards), >> + GDB should step over the entire line and not just a particular >> entry in the >> + line table. */ >> + >> +int >> +main () >> +{ /* TAG: main prologue */ >> + asm ("main_label: .globl main_label"); >> + int i = 1, j = 2, k; >> + float f1 = 2.0, f2 = 4.1, f3; >> + const char *str_1 = "foo", *str_2 = "bar", *str_3; >> + >> + asm ("line1: .globl line1"); >> + k = i; f3 = f1; str_3 = str_1; /* TAG: line 1 */ >> + >> + asm ("line2: .globl line2"); >> + k = j; f3 = f2; str_3 = str_2; /* TAG: line 2 */ >> + >> + asm ("line3: .globl line3"); >> + k = i; f3 = f1; str_3 = str_1; /* TAG: line 3 */ >> + >> + asm ("line4: .globl line4"); >> + k = j; f3 = f2; str_3 = str_2; /* TAG: line 4 */ >> + >> + asm ("line5: .globl line5"); >> + k = i; f3 = f1; str_3 = str_1; /* TAG: line 5 */ >> + >> + asm ("line6: .globl line6"); >> + k = j; f3 = f2; str_3 = str_2; /* TAG: line 6 */ >> + >> + asm ("line7: .globl line7"); >> + k = i; f3 = f1; str_3 = str_1; /* TAG: line 7 */ >> + >> + asm ("line8: .globl line8"); >> + k = j; f3 = f2; str_3 = str_2; /* TAG: line 8 */ >> + >> + asm ("main_return: .globl main_return"); >> + return 0; /* TAG: main return */ >> +} >> diff --git a/gdb/testsuite/gdb.reverse/map-to-same-line.exp >> b/gdb/testsuite/gdb.reverse/map-to-same-line.exp >> new file mode 100644 >> index 00000000000..c3fb859be55 >> --- /dev/null >> +++ b/gdb/testsuite/gdb.reverse/map-to-same-line.exp >> @@ -0,0 +1,141 @@ >> +# Copyright 2022 Free Software Foundation, Inc. >> + >> +# This program is free software; you can redistribute it and/or >> modify >> +# it under the terms of the GNU General Public License as published >> by >> +# the Free Software Foundation; either version 3 of the License, or >> +# (at your option) any later version. >> +# >> +# This program is distributed in the hope that it will be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program. If not, see < >> http://www.gnu.org/licenses/ >> >. >> + > > > Same. > > > >> +# When stepping (forwards or backwards), GDB should step over the >> entire line >> +# and not just a particular entry in the line table. This test was >> added to >> +# verify the find_line_range_start function properly sets the step >> range for a >> +# line that consists of multiple statements, i.e. multiple entries >> in the line >> +# table. This test creates a DWARF line table that contains two >> entries for >> +# the same line to do the needed testing. >> + >> +load_lib dwarf.exp >> + >> +# This test can only be run on targets which support DWARF-2 and use >> gas. >> +if {![dwarf2_support]} { >> + unsupported "dwarf2 support required for this test" >> + return 0 >> +} >> + >> +if [get_compiler_info] { >> + return -1 >> +} >> + >> +# The DWARF assembler requires the gcc compiler. >> +if {!$gcc_compiled} { >> + unsupported "gcc is required for this test" >> + return 0 >> +} >> + >> +# This test suitable only for process record-replay >> +if ![supports_process_record] { >> + return >> +} >> + >> +standard_testfile .c .S >> + >> +if { [prepare_for_testing "failed to prepare" ${testfile} >> ${srcfile}] } { >> + return -1 >> +} >> + >> +set asm_file [standard_output_file $srcfile2] >> +Dwarf::assemble $asm_file { >> + global srcdir subdir srcfile >> + declare_labels integer_label L >> + >> + # Find start address and length of program >> + lassign [function_range main [list >> ${srcdir}/${subdir}/$srcfile]] \ >> + main_start main_len >> + set main_end "$main_start + $main_len" >> + >> + cu {} { >> + compile_unit { >> + {language @DW_LANG_C} >> + {name map-to-same-line.c} >> + {stmt_list $L DW_FORM_sec_offset} >> + {low_pc 0 addr} >> + } { >> + subprogram { >> + {external 1 flag} >> + {name main} >> + {low_pc $main_start addr} >> + {high_pc $main_len DW_FORM_data4} >> + } >> + } >> + } >> + >> + lines {version 2 default_is_stmt 1} L { >> + include_dir "${srcdir}/${subdir}" >> + file_name "$srcfile" 1 >> + >> + # Generate the line table program with distinct source lines >> being >> + # mapped to the same line entry. Line 1, 5 and 8 contain 1 >> statement >> + # each. Line 2 contains 2 statements. Line 3 contains 3 >> statements. >> + program { >> + DW_LNE_set_address $main_start >> + line [gdb_get_line_number "TAG: main prologue"] >> + DW_LNS_copy >> + DW_LNE_set_address line1 >> + line [gdb_get_line_number "TAG: line 1" ] >> + DW_LNS_copy >> + DW_LNE_set_address line2 >> + line [gdb_get_line_number "TAG: line 2" ] >> + DW_LNS_copy >> + DW_LNE_set_address line3 >> + line [gdb_get_line_number "TAG: line 2" ] >> + DW_LNS_copy >> + DW_LNE_set_address line4 >> + line [gdb_get_line_number "TAG: line 3" ] >> + DW_LNS_copy >> + DW_LNE_set_address line5 >> + line [gdb_get_line_number "TAG: line 3" ] >> + DW_LNS_copy >> + DW_LNE_set_address line6 >> + line [gdb_get_line_number "TAG: line 3" ] >> + DW_LNS_copy >> + DW_LNE_set_address line7 >> + line [gdb_get_line_number "TAG: line 5" ] >> + DW_LNS_copy >> + DW_LNE_set_address line8 >> + line [gdb_get_line_number "TAG: line 8" ] >> + DW_LNS_copy >> + DW_LNE_set_address main_return >> + line [gdb_get_line_number "TAG: main return"] >> + DW_LNS_copy >> + DW_LNE_end_sequence >> + } >> + } >> +} >> + >> +if { [prepare_for_testing "failed to prepare" ${testfile} \ >> + [list $srcfile $asm_file] {nodebug} ] } { >> + return -1 >> +} >> + >> +if ![runto_main] { >> + return -1 >> +} >> + >> +# Activate process record/replay >> +gdb_test_no_output "record" "turn on process record" >> + >> +gdb_test "tbreak main_return" "Temporary breakpoint .*" "breakpoint >> at return" >> +gdb_test "continue" "Temporary breakpoint .*" "run to end of main" >> + >> +# At this point, GDB has already recorded the execution up until the >> return >> +# statement. Reverse-step and test if GDB transitions between lines >> in the >> +# expected order. It should reverse-step across lines 8, 5, 3, 2 >> and 1. >> +foreach line {8 5 3 2 1} { >> + gdb_test "reverse-step" ".*TAG: line $line.*" "reverse step to >> line $line" >> +} >> -- >> 2.31.1 >> > > ok. > > I'll send a v6 with the fixups. Thanks!