From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123967 invoked by alias); 7 Jan 2020 15:15:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 123947 invoked by uid 89); 7 Jan 2020 15:15:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:10.152.24.55, HX-Spam-Relays-External:sk:DB3EUR0, H*RU:10.152.24.55, H*RU:sk:DB3EUR0 X-HELO: EUR04-HE1-obe.outbound.protection.outlook.com Received: from mail-oln040092073071.outbound.protection.outlook.com (HELO EUR04-HE1-obe.outbound.protection.outlook.com) (40.92.73.71) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Jan 2020 15:15:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WsESXHbW7l87gmu/rZhwNcEaMfI4bYLuL+85+xjRlnMi9E9wJrsQ0uueWbi5I2tZL20XjqTGYnMihc6vMOIFtVZuFM2pUuElBnozya+i9psyr8AhNahcf5qP/F7rejxgss5COdeLAKAaHm1a26dY+auVl69G60Uj5MyEYOXF48PXc/715anN2vvMnPui3/ZBXMh0/Dy74Y9HIZ9mgwdTfsGybwDWjqTAAUuIVD6+kX1JzSn9U+2gaE05IB5pcz+/qpnUWoa9MYZbgLEccpbj/+auz56rG0xLlVbdaVx2yfOzpF8SorkNgkTooMTxz24bCo7hQ8oyxlV3V+fo4yQZ+A== 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-SenderADCheck; bh=F3LuZiIgAPDL+aMHy5bHEg2aP2gRgHUeEDbk3KlyS+c=; b=JEoGMB3CZO6lQh9/w4oy8GQpTyKcMyExxNgfXINO1z6XKzaj0YjLS4R/qi2plNzjyw4zU5WKftV0DOrzDNymCnNMPJCsg5AphJE6mnXoIkp2x0E+BaVgTxxhy/vMI0iJ6mkZQanYc/iy2iWfc/ptpDI0FloXin9nptpiM9nE4dnENU+L5tAnfDrVtQWiLWPJA1PNtRRLK9Rb4Xbl2FSsw3Jddjlo8yj42yoCXn1VgBj47IVmE2tncrjJQMAIur8CTKvgn2gT68rL3FIreVuJeYLprdmAu4KCmcdifjs7WC9UTWXgVgnCaOnSyc3u/D+gRzOdasKgr07QvaQ4yE8WYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB3EUR04FT018.eop-eur04.prod.protection.outlook.com (10.152.24.60) by DB3EUR04HT062.eop-eur04.prod.protection.outlook.com (10.152.24.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Tue, 7 Jan 2020 15:15:54 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.24.55) by DB3EUR04FT018.mail.protection.outlook.com (10.152.25.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Tue, 7 Jan 2020 15:15:53 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::c895:7517:78e7:1eac]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::c895:7517:78e7:1eac%7]) with mapi id 15.20.2602.016; Tue, 7 Jan 2020 15:15:50 +0000 Received: from [192.168.1.101] (146.60.252.106) by AM0PR06CA0055.eurprd06.prod.outlook.com (2603:10a6:208:aa::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Tue, 7 Jan 2020 15:15:49 +0000 From: Bernd Edlinger To: Andrew Burgess CC: "gdb-patches@sourceware.org" , Simon Marchi Subject: Re: [PING**3] [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Tue, 07 Jan 2020 15:15:00 -0000 Message-ID: References: <20200106220925.GU3865@embecosm.com> In-Reply-To: <20200106220925.GU3865@embecosm.com> x-microsoft-original-message-id: x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C37F83D4BA13B48A935CDE0D0584C4E@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2020-01/txt/msg00147.txt.bz2 On 1/6/20 11:09 PM, Andrew Burgess wrote: > * Bernd Edlinger [2020-01-06 08:14:37 +0000]: >=20 >> Hi, >> >> I'd like to ping for this patch again. >> The latest version (including testcase + changelog) can be found here: >> https://sourceware.org/ml/gdb-patches/2019-12/msg01052.html >=20 > I think we should investigate tracking the line table is_stmt property > better, as I suggested in another mail in this thread. >=20 Sure, no problem. I am fully aware that this is just a workaround. > I see you've provided some feedback to the patch I posted, I just > haven't had time to look at it yet, but will try to get to it as soon > as I can. >=20 Thanks, one additional thought I had about your patch: I believe that we should also look at implementing the variable-location-views. I mean adding a view number to the record_line function. That would mean adding PC.view in the line table. That could in theory be used to find out if a location view is inside a subroutine or in the main program, even if the PC is the same, using the view number it would be possible to find that out. That would allow us to step to the return statement of the inline function if we are stepping in the inline function and to step over the whole inline if we want to. The only part that is really missing for that is the view number in addition to the PC where the inline function ends. Note there is already a view number where the inline starts: <2><918>: Abbrev Number: 43 (DW_TAG_inlined_subroutine) <919> DW_AT_abstract_origin: <0x9b5> <91d> DW_AT_entry_pc : 0x40117b <925> DW_AT_GNU_entry_view: 0 <926> DW_AT_low_pc : 0x40117b <92e> DW_AT_high_pc : 0xa <936> DW_AT_call_file : 1 <937> DW_AT_call_line : 24 <938> DW_AT_call_column : 10 <939> DW_AT_sibling : <0x965> conceptually the subroutine starta at DW_AT_entry_pc/DW_AT_GNU_entry_view and ends at DW_AT_high_pc/, but the end view number is not yet specified. That IMHO is what should be added here. Bernd.