From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60045.outbound.protection.outlook.com [40.107.6.45]) by sourceware.org (Postfix) with ESMTPS id 02CF83858415 for ; Wed, 9 Mar 2022 14:54:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02CF83858415 Received: from DB6P192CA0023.EURP192.PROD.OUTLOOK.COM (2603:10a6:4:b8::33) by HE1PR08MB2858.eurprd08.prod.outlook.com (2603:10a6:7:33::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.20; Wed, 9 Mar 2022 14:54:02 +0000 Received: from DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b8:cafe::8b) by DB6P192CA0023.outlook.office365.com (2603:10a6:4:b8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14 via Frontend Transport; Wed, 9 Mar 2022 14:54:01 +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 DB5EUR03FT044.mail.protection.outlook.com (10.152.21.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22 via Frontend Transport; Wed, 9 Mar 2022 14:54:01 +0000 Received: ("Tessian outbound 826a6d8e58c3:v113"); Wed, 09 Mar 2022 14:54:01 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: edb6676cbb0eb933 X-CR-MTA-TID: 64aa7808 Received: from 2e10964833d7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7EEC8490-AAC2-4BCE-BC92-DE399799F489.1; Wed, 09 Mar 2022 14:53:55 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2e10964833d7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 09 Mar 2022 14:53:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TgZp+1IotPStdry6ojlwXpsQ06n2WmROBiK7MlXQBnBZOlG1Ak4zrr5PQjhw5IsWZfjEdbn2Vu5Vb0HVaOkG2M2hvv5GAOBkHU3AF+KdKbskn7FJm1vttaPJ1DW0HerW/+fDweiM6nunUhg2EloE7g/RgH5SqGxO0+AkLUpBsf8G75JmeXYv/GkgkoGOVlcsjPn/RUXUCSYgMh6OSGF+AXvADSrkho2LMR5wwOIbjFdGo4DLCQSWs8kHBlPI8QDBHWzEp349j3OawvnjBXKbj+nYUCyUbSGHNQyvBuZz1E1UY39z/4Ox1t8FSHKKQ2cgekaf6ya5kQtpLneuV8So4A== 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=wFdTD6M4kps90v4BkkaBmKXYV4HsnDW+L3bg7MsYPRw=; b=WFM2lqNfENYT/57QYQ46IQ2UQDIqHjcNj4NDrSNUcREVZCA8OCnowTmi0Mk0ihyxl5Mpq1Y6ikZwqxu/ZlrWy30FKy58ZHH8K8ggwVmU6lJkUomcKMNSXJrnlswqnvR2xXt86+GNkvNb9y5Jc1bNw+tTGGcmn5SA8XoGzKtf2/3dkcDZdZ+on1A3sV10+ZQM1K4235kKnQGwqB5ZN+Upu5eVZVJYd23YjPLpIRkDpItHb3M8NyKqKhqsRk/2lbghtSiVph7fCeZdiTB4RG2voTtHvL94bzx68yKomsYQzAQ/4fByc+Fz6haeTcNIv6jNqf8u/fJnQNcLaKSzz8xXJQ== 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 AM0PR08MB3748.eurprd08.prod.outlook.com (2603:10a6:208:fb::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14; Wed, 9 Mar 2022 14:53:54 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::457d:362e:8883:dd2a]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::457d:362e:8883:dd2a%7]) with mapi id 15.20.5038.027; Wed, 9 Mar 2022 14:53:53 +0000 Message-ID: Date: Wed, 9 Mar 2022 14:53:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH] Updated, fix reverse stepping multiple contiguous PC ranges Content-Language: en-US To: Carl Love , Bruno Larsen , gdb-patches@sourceware.org Cc: Rogerio Alves References: <442684e3f81aa1df073960bd45918106acefa2b9.camel@us.ibm.com> <0fbaf3783401f8aa8e76a4d3928efff46485ab8d.camel@us.ibm.com> From: Luis Machado In-Reply-To: <0fbaf3783401f8aa8e76a4d3928efff46485ab8d.camel@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0015.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::20) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c10ca6bf-5a3d-4af3-70eb-08da01dca5fa X-MS-TrafficTypeDiagnostic: AM0PR08MB3748:EE_|DB5EUR03FT044:EE_|HE1PR08MB2858: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: gxcYc6czmv65Oo9Q+w0gr2bRIriCqNpP7R8OHVaOXjq3+X/WV79QfAr2buJc7CperC+bKixmRlod2vOFUf6WC7lTf/Dyndpp3ff43+MQbYEuHTjvrZV/XIZ591dNJJ9aAnDqeh4Ov7+p8nijhjtTcXyqY2H6pt0wG+mRvGSI/b6pyWWmT8jIiSbKL2XktludUGhpOnwemH7MkGOreG8eDIEJ0f/XkbsI+DE9U6RlQmqSlCvzMFjKLTO50pPIcZ3n3ygg7wH3/NY56vyzCiYwbpGqONt3RVmhkdglPRF/U5wn02ytS/gi5f0rSiKcApohxD/vbYr4Ql2m5Kx/65pzWtX0sVy+Xu6LkN4keIwZ9fS4arl0zlfTTVp1hn6SWq4wW2nokGETdOHiuJJ7qBCwY4SoMAB+3gOGAVA8EjJ5ouxy2oAYLT1GdYlcrUFkFnM66TJ2n/o5kaVkhtbENaHubpaLTIaBvO6ykukhmMs5UqnS496oiO/kz8xh7Yw4BOBFXTVva8P6aqk1bGrHHKh0TL3GEJGWgC2UQWDAIUk3OQ4/KD6dqNH4bJPENM9F6/p55qBn6HyMrxlvIM+C1VlFpbjeFW7tZq2wJee6K6YSG0MseFHf5V7rOLMrr1xLUddkOmegsBwvPSlEwiFYc+7QTX+VdV4xo5eqIjxEAE3eRPEWn6mv/GG/3N8jQigTiZypeLH9LZqwkPdLKODhuz44MwZNN7ctZV/qqYg3aOb5wqL6HiqVN81LLjnhBAnJBG1nlkEiUyjxkcDQOsmhVK8yn2896z0bO2PVRIuOLciouXUEgJey/X9DjugYmg0ahC1a 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)(86362001)(84970400001)(6486002)(38100700002)(83380400001)(31696002)(26005)(186003)(4326008)(66556008)(66476007)(8676002)(2616005)(15650500001)(316002)(44832011)(36756003)(2906002)(8936002)(66946007)(5660300002)(6506007)(53546011)(6512007)(31686004)(508600001)(110136005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3748 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: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 0adc7e1a-91a8-412c-831b-08da01dca155 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mOgUwSBIt3tE64pCr4+B8nMtbjk0awlFyQPJHgkmOg8lEW3svpe+H0z00hASW8QcA9vSx/a39Ip78GdaABJld7E/HiahDW/uaTs0/FB8jqKTbWOgNxF8lGO/hm7eX0I+AFFgpdix4Jjir4NUD2IL9YOXQ4t4p0mKrutC6qq7ZjYWxLYhJp9+N5HUMbDGxpIfBXZ33OmA8Toe6hHRky1c2QILdzP/kMwWgcWSa7v3YWszjm9D8SEOiCOBSjYqkYz0ZPfzxVW8pECWHa1c/k7KkuL7eqvNjfnUQexFHynKupv2tm3Z76wsDHBSbOFX3VUy+dVqr4jzj6qWlYe3y0hj4fiPQFEnxLVP7XBWhkqN51cALtwZ5iXTUceTV1kE4qTwEzI0XxvF2JtTpNoomd5jDGeJYDlH4fRWE8T5iRxR/N53N06ZUD2TIVi63fCCKVwqHGcvFWU8djqoqCOZ3MmHxmnYBbQaYPDyHSJW8jQ/yZ+IIkCRX5oNdgOHQZHCzquXuZvrZ2EiNt0DeIMqU0z36n0UhYj+WTpj9jEjiuVB9VM1VTFe0bELV17fwV4vzH/ZVzj340l3E3yxgIXvv3WXw+HQ+9zFfTVeAxI2X2rcVoBdr4+viwGPeieb/TMCSUWLAx5XLVjFVg7eHVYA8NiNoODBIkVg9177upoAqQTUeENeK3ktfOIlT1hOG9wCqX1YSFAgtydMEluYOPBMaKRtw4cVwGR6iumP5f23Hj6jWxfi88aDaYgE4vEi4KW+WlbWqV25NK9TY4+1F5eLkP7zmTurFhilfc5WlNZvzqycm7s= 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)(46966006)(36840700001)(40470700004)(336012)(5660300002)(47076005)(81166007)(36756003)(6486002)(83380400001)(8936002)(31686004)(6506007)(2616005)(6512007)(508600001)(53546011)(186003)(110136005)(316002)(70586007)(70206006)(4326008)(356005)(26005)(82310400004)(84970400001)(86362001)(31696002)(40460700003)(15650500001)(2906002)(8676002)(36860700001)(44832011)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2022 14:54:01.5338 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c10ca6bf-5a3d-4af3-70eb-08da01dca5fa 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: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2858 X-Spam-Status: No, score=-13.1 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: Wed, 09 Mar 2022 14:54:24 -0000 Hi Carl, Sorry for the e-mail bounce. I can revisit this one, as I still see the same failures. Hopefully I'll have some time to address some of the concerns from past reviews. I'll need to refresh my memory on what it was about. :-) Regards, Luis On 3/8/22 22:01, Carl Love via Gdb-patches wrote: > On Tue, 2022-03-08 at 17:21 -0300, Bruno Larsen wrote: > > >> >> >> 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 >> > > I have not writen anything in dwarf assembler in the past. Off the top > of my head, don't know how to create such a test case. It does seem > that there are the two testcases gdb.reverse/solib-precsave.exp and > gdb.reverse/solib-reverse.exp which the patch fixes. I guess the dwarf > assembly test would be similar to the C level code. > > Do you have an example of how to write dwarf assembly or a pointer to a > tutorial on writting dwarf? > > I will work on the two comments you had on the patch. Thanks for your > time reviewing the patch. > > Carl > > >>> ----------------------------------------------------------- >>> From: Luis Machado >>> Date: Mon, 21 Feb 2022 23:11:23 +0000 >>> Subject: [PATCH] Fix reverse stepping multiple contiguous PC ranges >>> >>> 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 376a541faf6..997042d3e45 100644 >>> --- a/gdb/infrun.c >>> +++ b/gdb/infrun.c >>> @@ -6782,11 +6782,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 fi> + >>> + >>> + 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 >> >> I think this could be moved to the line above. >> >>> && execution_direction == EXEC_REVERSE) >>> end_stepping_range (ecs); >>> diff --git a/gdb/symtab.c b/gdb/symtab.c >>> index 1a39372aad0..c40739919d1 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; >> >> Shouldn't prev_sal.line also be checked here and return an empty >> optional? I am not sure when that happens, so please enlighten me if >> there is no need to check. >> >>> + } >>> + >>> + 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); >> >> >