From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13030 invoked by alias); 20 Dec 2019 19:57:29 -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 13021 invoked by uid 89); 20 Dec 2019 19:57:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=impression, H*r:10.152.1, H*RU:sk:HE1EUR0, infos X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092066092.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (40.92.66.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Dec 2019 19:57:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AIis8w6OdiHOosfDbkT5xCLG1rQwsjFFKrNmoInDXNvH6oEuEP5R5UoWZZsdaJzJalorXFDWIxQV7Wd3M68hwhgsFp2qM0EIkmsVKJBJeVe5zl+I/WOUDEvFZU4cCTNkCtDcmoh/IGdKLNzI0UFkadqAmIuH83p3wi+mZL5ySunK4UYpAFh8gSIM5F1qTXftssbvarMWr0gFC9KepeZSEN38eczDaNUwjTp6i5XQeThYpaY064/zKEINuRt25O4SL5IzQBm7nEOw6OyyOIs68QtOkb/vB9o9gi4eo0uhyg7CVu+nwtsJjdkqCNkQOmyB8/G6qmAjO+KUkQpHUoNhlg== 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=JsSh9DyXshJR63ciAz7F7DHcBeA2jpcT80HTDO7iFFY=; b=WIwNKYN0vvqRrSadPXtXsjzoFNrvKxc5UEBv0y0v64gRl5waeW9gX0kXSkCkkaknlPZCEMmeDPWALpT58enLXiJzCY6509GOAn/VOWVKoBEFP7OQDuRMAw0vLYgwMaPyfET8LMMVl696htwwKAZRZn1L0DEY+9sr4FjzZgdfuFhLgiqOlNiNjEd4wuzfFJhiS+th9ziGG1X/d8VCOWtZfIm8L/sUaI6qkrqMZriO50JuyEYE2MT24NBDuiHeGtPBLXhjcfMpid4628AC29L1TOF8X4BZTw2l1Xq4dJ02nJfwAIHxAreHN45qZAhsq17ivfNRRTsf2/2rbBegTrhMeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR01FT054.eop-EUR01.prod.protection.outlook.com (10.152.0.55) by HE1EUR01HT200.eop-EUR01.prod.protection.outlook.com (10.152.1.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2559.14; Fri, 20 Dec 2019 19:57:22 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com (10.152.0.55) by HE1EUR01FT054.mail.protection.outlook.com (10.152.1.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Fri, 20 Dec 2019 19:57:22 +0000 Received: from AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769]) by AM0PR08MB3714.eurprd08.prod.outlook.com ([fe80::8dd1:fb18:6271:f769%7]) with mapi id 15.20.2559.015; Fri, 20 Dec 2019 19:57:21 +0000 From: Bernd Edlinger To: Simon Marchi , "gdb-patches@sourceware.org" CC: Tom Tromey Subject: Re: [PATCH] Fix an issue with the gdb step-over aka. "n" command Date: Fri, 20 Dec 2019 19:57:00 -0000 Message-ID: References: In-Reply-To: x-microsoft-original-message-id: <22e8446e-b3ff-bbce-9a95-13a700c4be36@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_003_AM0PR08MB3714C7AC2142F1B6ACB47F09E42D0AM0PR08MB3714eurp_" MIME-Version: 1.0 X-SW-Source: 2019-12/txt/msg00925.txt.bz2 --_003_AM0PR08MB3714C7AC2142F1B6ACB47F09E42D0AM0PR08MB3714eurp_ Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Content-length: 4068 On 12/20/19 7:13 AM, Simon Marchi wrote: > Hi Bernd, >=20 > On 2019-12-19 5:53 p.m., Bernd Edlinger wrote: >> Does this explanation make sense? >=20 > Yes. Well I think so, I have to admit this is a bit over my head, > there are a lot of pieces to put together to have a good understanding > of the problem. I just did a first read, I'll sleep on it and come > back to it later. >=20 > Thanks for the small reproducer, this is extremely valuable. I think it > will be a good idea to integrate it as a test case in the test suite. >=20 > In your patch to dwarf2read.c, I was a bit surprised to see: >=20 > m_last_subfile !=3D m_cu->get_builder ()->get_current_subfile () >=20 > So your fix only works if the inlined subroutine comes from another file?= If > I move the tree_check function in next-inline.cc, the fix no longer appli= es, > and we get the broken behavior. From your previous email, I understand t= hat > this is expected. I guess that if both are in the same file, we can't de= tect > this situation using the same technique. Yes, when the inline function is not in a header file that will not help. But it solves 90% of the problem with a simple and obvious heuristic. To attack the rest of the problem we would need to know the PCs where inlin= ed subroutines and each corresponding range infos do end, but that data is only available long after the line info is parsed. >=20 > I also read about location views, since that's what Alexandre referred to= . It > sounds like it's a magic solution that will allow GDB to do the right thi= ng in > this kind of situation. If that's indeed the case, then it might be good= to start > exploring this path. I'd like to have a better understanding of how this= will help > GDB make a smarter "next", and what kind of effort is needed to make GDB = use it. My > understanding is that location views allow having an address mapped to mu= ltiple > source locations. For example, here's the problematic address in the nex= t-inline > test case I've compiled: >=20 > ./next-inline.h:[++] > next-inline.h 28 0x1175 = x > next-inline.h 30 0x1175 = 1 x >=20 > ./next-inline.cc:[++] > next-inline.cc 22 0x1175 = 2 >=20 I think the main problem here, is that from the line numbers alone it is no= t clear which of these location infos is in the subroutine and which is in the caller. The only link is the program address which is ambiguous at the end of the i= nline block. So my impression is that we need a connection between the location views an= d the inlined subroutine info. > Today, when I ask GDB "which source line does this address correspond to"= , it gives me > one answer. Does this mean that GDB will now say that 0x1175 corresponds= to >=20 > - next-inline.h:28 > - next-inline.h:30 > - next-inline.cc:22 >=20 > all at the same time? Is one of these source locations more important th= an the others? > If execution happens to stop exactly at this address, which location do w= e present to > the user? >=20 No idea. That will likely be confusing. > And to come back the problem at hand, how does this help GDB make a smart= er "next"? >=20 > Btw, I stumbled on a bug with the TUI source display. It might be caused= by this patch, > or it might be that this patch uncovers it. >=20 > When I do these actions: >=20 > - Start GDB with the next-inline test file (from this patch) > - Enable the TUI > - Type "start" > - Type "s" > - Type "n" twice >=20 > The TUI source display wrongfully jumps to the header file, line 24. > When I type "frame", it says I'm stopped at next-line.cc:24. So it > is showing the right line number of the wrong file. >=20 Ah, yes. That is already preexistent. Consider the attached idea for a test case. I have no idea yet how to make a working test case out if it. But I can fix the tui bug, it is quite easy. I will send a patch for that in a moment. Thanks Bernd. --_003_AM0PR08MB3714C7AC2142F1B6ACB47F09E42D0AM0PR08MB3714eurp_ Content-Type: text/x-csrc; name="step.c" Content-Description: step.c Content-Disposition: attachment; filename="step.c"; size=917; creation-date="Fri, 20 Dec 2019 19:57:21 GMT"; modification-date="Fri, 20 Dec 2019 19:57:21 GMT" Content-ID: Content-Transfer-Encoding: base64 Content-length: 1245 LyogVGhpcyB0ZXN0Y2FzZSBpcyBwYXJ0IG9mIEdEQiwgdGhlIEdOVSBkZWJ1 Z2dlci4KCiAgIENvcHlyaWdodCAyMDE5IEZyZWUgU29mdHdhcmUgRm91bmRh dGlvbiwgSW5jLgoKICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7 IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKICAgaXQg dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj ZW5zZSBhcyBwdWJsaXNoZWQgYnkKICAgdGhlIEZyZWUgU29mdHdhcmUgRm91 bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwgb3IK ICAgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KCiAgIFRo aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0 IHdpbGwgYmUgdXNlZnVsLAogICBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7 IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgogICBNRVJD SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UuICBTZWUgdGhlCiAgIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv ciBtb3JlIGRldGFpbHMuCgogICBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQogICBh bG9uZyB3aXRoIHRoaXMgcHJvZ3JhbS4gIElmIG5vdCwgc2VlIDxodHRwOi8v d3d3LmdudS5vcmcvbGljZW5zZXMvPi4gICovCgojaW5jbHVkZSA8c3RkbGli Lmg+CgpfX2F0dHJpYnV0ZV9fKChub2lubGluZSwgbm9jbG9uZSkpIHN0YXRp YyB2b2lkCmJhciAoKQp7Cn0KCiNpbmNsdWRlICJzdGVwLmgiCgppbnQKbWFp biAoKQp7CiAgaW50IHg7CgogIHggPSAwOwogIGZvbyAoKTsKICBhYm9ydCAo KTsKICByZXR1cm4geDsKfQo= --_003_AM0PR08MB3714C7AC2142F1B6ACB47F09E42D0AM0PR08MB3714eurp_ Content-Type: text/x-chdr; name="step.h" Content-Description: step.h Content-Disposition: attachment; filename="step.h"; size=827; creation-date="Fri, 20 Dec 2019 19:57:21 GMT"; modification-date="Fri, 20 Dec 2019 19:57:21 GMT" Content-ID: Content-Transfer-Encoding: base64 Content-length: 1123 LyogVGhpcyB0ZXN0Y2FzZSBpcyBwYXJ0IG9mIEdEQiwgdGhlIEdOVSBkZWJ1 Z2dlci4KCiAgIENvcHlyaWdodCAyMDE5IEZyZWUgU29mdHdhcmUgRm91bmRh dGlvbiwgSW5jLgoKICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7 IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKICAgaXQg dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj ZW5zZSBhcyBwdWJsaXNoZWQgYnkKICAgdGhlIEZyZWUgU29mdHdhcmUgRm91 bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwgb3IK ICAgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KCiAgIFRo aXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0 IHdpbGwgYmUgdXNlZnVsLAogICBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7 IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgogICBNRVJD SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UuICBTZWUgdGhlCiAgIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv ciBtb3JlIGRldGFpbHMuCgogICBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQogICBh bG9uZyB3aXRoIHRoaXMgcHJvZ3JhbS4gIElmIG5vdCwgc2VlIDxodHRwOi8v d3d3LmdudS5vcmcvbGljZW5zZXMvPi4gICovCgpfX2F0dHJpYnV0ZV9fKChf X2Fsd2F5c19pbmxpbmVfXykpIHN0YXRpYyBpbmxpbmUgaW50CmZvbyAodm9p ZCkKewogIGJhciAoKTsKfQo= --_003_AM0PR08MB3714C7AC2142F1B6ACB47F09E42D0AM0PR08MB3714eurp_--