From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60080.outbound.protection.outlook.com [40.107.6.80]) by sourceware.org (Postfix) with ESMTPS id C29B7394742D for ; Tue, 22 Mar 2022 17:10:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C29B7394742D Received: from AM6P193CA0085.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::26) by AM9PR08MB7273.eurprd08.prod.outlook.com (2603:10a6:20b:434::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14; Tue, 22 Mar 2022 17:10:30 +0000 Received: from VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:88:cafe::1c) by AM6P193CA0085.outlook.office365.com (2603:10a6:209:88::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.17 via Frontend Transport; Tue, 22 Mar 2022 17:10:27 +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 VE1EUR03FT034.mail.protection.outlook.com (10.152.18.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14 via Frontend Transport; Tue, 22 Mar 2022 17:10:27 +0000 Received: ("Tessian outbound 341d209a0e52:v113"); Tue, 22 Mar 2022 17:10:27 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e8ce0389583ad35a X-CR-MTA-TID: 64aa7808 Received: from 988ff827e8ea.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id DA68FAB7-22F5-42B7-96C0-24E18DA83D9C.1; Tue, 22 Mar 2022 17:10:20 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 988ff827e8ea.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 22 Mar 2022 17:10:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G+Pkn+yVHUQVj7rncQZj7rQ3G69Rylhsk7/BgaNOECzIG9vAFs+wYVEN5xjHeLs0rCq1cKVBOKot+oi5oO+2IAoFoo5Jf3EsW1jStTKZe/70IdDhoUctqUv0Bn1YBNRbvvkjsdNr1xEVIpS2t0CegfqjYP0Dn/P0PHz1gJmmwIJSpiF9wCvnH/o9+M3tYPrBf2etku5tZr778O5rxgJsDA1ae/82tSqnLZiZ2VP+sPYZNtvTkLqkyFhrw+4tBwxK8vvTTugRrUFaNly8RHc6QdiOhF4eX9nwKXLgk0CZs3gW+0SUxa2Ylsi9oJNo0mMPhrCdXx9wn5A5GPVK0L9Xvg== 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=+nrYM4knHAZx2ytnlWrYbFJ4hOSAMC9RLNWo/fG57cQ=; b=d0rRr0RzdcPrsm4aAmbsHfmINu8yuNhzIt+FienCu//uFmOEZP/GAYW2WQ7gXdQwGluKPqPbnR2qHFazZpxBsYzTaSt0cKa5U3JrVS49vI1fpKffDABMFTWaEAYc8KZZaW4W2WfyVksce2uTg/9kuzBG2jvsLxyWt1uR5uNj/c/z/cLWMouSfz/emuhqeTK5pozyu0j946GOrCIk146EchRvezqEHmQuZ3egd9aO973sEKP71XSudO0q22sglu799nou0Xu0rO2Z/orPCvfOUSx2r3Q7xiJCRWepyCEx6NJCc9zFpxtQ2jQqrPUFz8JcyLNrrFqxTEzvfFW/pWJbRg== 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 AM7PR08MB5301.eurprd08.prod.outlook.com (2603:10a6:20b:dd::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.16; Tue, 22 Mar 2022 17:10:17 +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.5081.023; Tue, 22 Mar 2022 17:10:16 +0000 Message-ID: <80cb0ff0-1569-cdf2-c102-b2ec7a6d2775@arm.com> Date: Tue, 22 Mar 2022 17:10:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V2] Updated, fix reverse stepping multiple contiguous PC ranges Content-Language: en-US To: Carl Love , Bruno Larsen , gdb-patches@sourceware.org Cc: Rogerio Alves , Will Schmidt References: <442684e3f81aa1df073960bd45918106acefa2b9.camel@us.ibm.com> <7a429c919395db6ec4642803badca5dbb97bff66.camel@us.ibm.com> <90f842721dc87da4052ae860c8ee09286dae0012.camel@us.ibm.com> From: Luis Machado In-Reply-To: <90f842721dc87da4052ae860c8ee09286dae0012.camel@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0219.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a6::8) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ea5356f3-2f3e-4f1f-7e68-08da0c26dc92 X-MS-TrafficTypeDiagnostic: AM7PR08MB5301:EE_|VE1EUR03FT034:EE_|AM9PR08MB7273: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: e9JQnXFfpmkBG9fBJZeMXIUtbSipVP8uzOL4g7uPY1h/qo56brEdkUSuBiLY5llDeFeGxa4k1DU8z0ZLC56bSsEc7wEjX6TvI7e6GzuP36AlsCJzwggpG68QLsW8UnFqZwCOT7h9f0Kq0gNcjP+PRW2kRb+74U325BIieofozlZPusDJGYvNa3JucHhl0iMbybPXJYtM/6BmkIu27mKGwNsc7jGvWbDlsD0cTtt4isou0Y09YuJLzG4Hd5TrbPUB7rXatU6OJCXQuWEiGY+aoGjGkREPmB7B3jWlrbkcFsUA/ytGaPoYvRUb7ttl9EngjTMZhsrmk2+I3PvZdbMXmlPIX3wxem7vvNDtJqm954jrTo6WYFolLGUtIypvHCk9sJpw5XzeeWSrq8ytE9aorjfxvVwAz8J9aKzPSEHlmKUg5choMBht4YJKyMl8i2Wjiq7GfFVv0Gdrqs0VWivGaxmzxH554WNB6VzbfLLiWic+aTwYIhGfS2l/O3/keSlypxTCKAAHelgYEvMRRhskoVSgWMcON8IjrExfO6GUmBLsCRL/JEin4TpJWDFYa2m4lqaDMargXqaweJQuXHm+xu7MLaMx7u77kwwn8ndV3kD4hFsp6ozlqVLuKyg+NU1sIUMTpWDNbEg+z647mMvbh1k2GuqSYvpPovHoXcRV61hFIxhXOLHrabEEDzhxnNa8sHSF0SO/24lDEjNIX0Pbjp3WsA/L1xs19s5yjH8E9WNf5SzBgxiKmQt1KJO+klVWujJzxoHOANxiuwFtq/5PLv1cgnicmGCD1X9G9v5vimoqWgPCgxAjkGKyQ+IMqe5D 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)(44832011)(38100700002)(83380400001)(2906002)(86362001)(6486002)(508600001)(8936002)(15650500001)(5660300002)(31686004)(316002)(2616005)(26005)(186003)(4326008)(36756003)(110136005)(66476007)(66556008)(54906003)(66946007)(84970400001)(31696002)(53546011)(6506007)(6512007)(6666004)(8676002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5301 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: VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 91a45f9f-4b6f-4d6c-333b-08da0c26d5d1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ftU/rqYN3AY3nC0K/PyxLgMmKqUdXIAWthaTQAHYPPSYrcNbmTZNOUH8q0yImyXiFV3bBD9BA9hg8mL8RUeeitV/8FAxItk6bmhxSljYueeBvtd4iB9UROLWgHjhIsdiViVMz/g2+s4lriedGpbKUK+5rk0U0KM5PCFIRd0R5JhMY1v1x3BAbuJUJ1UMPMTyrEemGkU6YNojTgsMhTx55WJ4nCKf0ig2rkbymLN2zFvaqliDoNzJJ50jO1oOOxk0Z3f5y4sZ8m1+FWnIz/N7apDS9Do72hcYjB+7ELkf0sM8oooSxFNeExSoSnmu9xUejS3cly2ZxMPMO0NQAXYXvx/RMC0MxYDIKKC5YWB5QNBw5IgWKy++5S8b56lAoF7qu6OrNKJ3ZPBZQOAQhvbVDsrMW2TqGuO/dS79HkNIYEFnBIHhZ7CpCrsjkWHKzCvJ93V1N6De0rW2aI2QpMJQ23HvxWw4iMhgeXM/DpwNz67q+shOwiR1yBYzz6j9yGjcKUjwuvcdxE0ImSMAcarlaTCFvq9LtzqRhsUPPmD7UXT1Z2xaSe8AeiFycLm8JDblEbnR2AE4wro3Lch9ozXZ4d9uysTTy0GEeIXnKhMCSKKOW5W2pvHb57vdeJBhQSa/F/Rr2pODIhujQ5IAd5Lrr7Gz0aHuCx6Sa8Zx4l/srkPau8D4wWL471YZ6HW7UlkLhenfz4i/slllKXeiKsbDNKbUtqgg0pptlFJtospN0eelhdfzw08jzRL0etTgZGniE9KkvyWX/9MCdoUuCNVRtsiPOMwT0E2QJvmtN9UzWpg= 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)(53546011)(6512007)(31686004)(356005)(31696002)(40460700003)(81166007)(36860700001)(6506007)(336012)(8936002)(2906002)(36756003)(508600001)(86362001)(6666004)(2616005)(6486002)(82310400004)(5660300002)(84970400001)(8676002)(15650500001)(47076005)(316002)(70586007)(70206006)(4326008)(110136005)(54906003)(83380400001)(186003)(44832011)(26005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2022 17:10:27.3819 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea5356f3-2f3e-4f1f-7e68-08da0c26dc92 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: VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB7273 X-Spam-Status: No, score=-12.8 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 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, 22 Mar 2022 17:10:45 -0000 Hi Carl, Thanks for working on the testcase. I have some minor changes to the patch. Mainly incorporating Simon's suggestions from the first review. Instead of comparing just the line, the updated code compares the line number and the symtab. If both match, then it means we're dealing with the same source file. I'll rebase it and will post it soon. On 3/22/22 17:05, Carl Love wrote: > Bruno, GDB maintainers: > > I was asked to clean up the message a bit to clarifiy the message. > Changing this to version 2 since it now has an additional test added to > the patch and a code fix. > > The following patch was posted by Luis Machado on 2/1/2021. There was > a little discussion on the patch but it was never fully reviewed and > approved. Luis has a new email address: luis.machado@arm.com. > > As of 2/21/2022 the patch did not compile. I made a small fix to get > it to compile. I commented out the original line in gdb/infrun.c and > added a new line with the fix and the comment //carll fix to indicate > what I changed. Clearly the comment needs to be removed if the patch > is accepted but I wanted to show what I changed. > > On Tue, 2022-03-08 at 17:21 -0300, Bruno Larsen wrote: >> Hello Carl! >> >> Thanks for looking at this. Since I don't test on aarch64 often, I am >> not sure if I see regressions or racy testcases, but it does fix the >> issue you mentioned, and there doesn't seem to be regressions on >> x86_64 hardware. I have a few nits, but the main feedback is: could >> you add a testcase for this, using the dwarf assembler and manually >> creating contiguous PC ranges, so we can confirm that this is not >> regressed in the future on any hardware? >> >> Also, I can't approve a patch, but with the testcase this patch is >> mostly ok by me > > The attached patch includes a stand alone DWARF test to verify the > patch works. The test has been verified on i386 and Powerpc. > Additionally the two lines in infrun.c were combined onto one line as > Bruno mentioned. > > As mentioned Bruno can not approve the patch. Hopefully on of the GDB > maintainers can give us an additional review to let us know if the > patch is acceptable. Thanks. > > Carl Love > > ------------------------------------------------ > Fix reverse stepping multiple contiguous PC ranges > > The following patch fixes 5 test failures in gdb.reverse/solib-precsave.exp > and 5 test failures in gdb.reverse/solib-reverse.exp. Both testst pass on > Intel 64-bit. The two tests solib-precsave.exp and solib-reverse.exp both > initially passed on Intel without the patch. > > No additional regression failures were seen with the patch. > > A new testcase was added using DWARF statements to reproduce the issue as > described below. The new testcase has been tested on x86 and Powerpc with > the patch to that the test case fails without the patch. The issue is fixed > on both platforms with the patch. > > When running GDB's testsuite on aarch64-linux/Ubuntu 20.04, 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 1 will land on line 2. > - step from line 2 will land on line 3. > > Reverse execution: > > - step from line 3 will land on line 2. > - step from line 2 will land on line 2. > - step from line 2 will land on line 1. > > The problem here is that line 40 contains two contiguous but distinct > PC ranges, like so: > > Line 40 - [0x7ec ~ 0x7f4] > Line 40 - [0x7f4 ~ 0x7fc] > > When stepping forward from line 2, we skip both of these ranges and land on > line 42. When stepping backward from line 3, 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->suspend.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. > > I'm not particularly happy with how we go back in the ranges (using "pc - 1"). > Feedback would be welcome. > > Validated on aarch64-linux/Ubuntu 20.04/18.04. > > Ubuntu 18.04 doesn't actually run into these failures because the compiler > doesn't generate distinct PC ranges for the same line. > > gdb/ChangeLog: > > YYYY-MM-DD Luis Machado > > * infrun.c (process_event_stop_test): Handle backward stepping > across multiple ranges for the same line. > * symtab.c (find_line_range_start): New function. > * symtab.h (find_line_range_start): New prototype. > > Co-authored-by: Carl Love > --- > gdb/infrun.c | 24 +++++++++++++++++++++++- > gdb/symtab.c | 35 +++++++++++++++++++++++++++++++++++ > gdb/symtab.h | 16 ++++++++++++++++ > 3 files changed, 74 insertions(+), 1 deletion(-) > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 0e819553aeb..0fcfd0fb10e 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -6779,11 +6779,33 @@ 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, > + 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->suspend.stop_pc); > + = find_line_range_start (ecs->event_thread->stop_pc()); //carll fix > + > + > + 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); > diff --git a/gdb/symtab.c b/gdb/symtab.c > index a867e1db9fd..600006c7843 100644 > --- a/gdb/symtab.c > +++ b/gdb/symtab.c > @@ -3425,6 +3425,41 @@ find_pc_line (CORE_ADDR pc, int notcurrent) > return sal; > } > > +/* 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 {}; > + > + 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 (prev_sal.line != current_sal.line) > + return current_sal.pc; > + > + /* 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 (prev_sal.line != current_sal.line) > + done = true; > + } > + > + return prev_pc; > +} > + > /* See symtab.h. */ > > struct symtab * > diff --git a/gdb/symtab.h b/gdb/symtab.h > index d12eee6e9d8..4d893a8a3b8 100644 > --- a/gdb/symtab.h > +++ b/gdb/symtab.h > @@ -2149,6 +2149,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. > +*/ > + > +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);