From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id bKCoImLZC2CdPwAAWB0awg (envelope-from ) for ; Sat, 23 Jan 2021 03:08:02 -0500 Received: by simark.ca (Postfix, from userid 112) id 74B9B1EF80; Sat, 23 Jan 2021 03:08:02 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=FORGED_MUA_MOZILLA, FREEMAIL_FROM,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,RDNS_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DC9021E945 for ; Sat, 23 Jan 2021 03:08:01 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 89463385801A; Sat, 23 Jan 2021 08:08:00 +0000 (GMT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-oln040092066059.outbound.protection.outlook.com [40.92.66.59]) by sourceware.org (Postfix) with ESMTPS id 12583385801A for ; Sat, 23 Jan 2021 08:07:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 12583385801A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bernd.edlinger@hotmail.de ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pfb9sCaii+GXpkumueONIUsy52GHQLDInplEf3Q4hR8buWsxncX8H5awXz/89WefyDtUGJMZXXdjCLZa6nKvRemF4d3VSonCpRoKuMEH/JkpcMgKAK8yqU9Sy8Kn6DhRIUujEg2p8siwJjWT6LprlmeksNCLqQvD+ERC+36AfGb0Xw+7NicsJP46w+0PLQLBCfhKivHXIBJQlb3tYDOZpOytvQNt5KBnywaV+JXgaIHRO3J8J4KEWUUVJ9pMZbGwE47ompmzx6wLQLPPDreQZ8Qmz+9yBA0aprpQzeuUR4WnpMZlLc464xZ4HcBokPsC4iNlGBtwQja/F1eIxDpW5A== 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=Jj6HnEGILFyC5wQbMKKSnJ86SfVEGcgr7BsVlFeBskU=; b=e75pd2ZdFTYosZZz5CM1atm4+VsiVxX7lDVsUMXRT6ClwnmKeEjP6k8gw8157Y1D3F6D21212BApBvCs4T4eo4v7TbubX3YLjRlv93lLc+SopQixOoWkPK4A2gixpeJ9dv0zx76WR/vxOETW0gsEnrzbIiO7GZ9Va/uohZ5Ycio70dDnJPfrkW8pzY+MTY22nxzkCBjXADHXs75ta2Abb1+jOZtJksxkRxbrIgUxNyvZ/7NN+ISRXq8E0qG8yb5XfhPBVgzSfDcoJ6ZHHdoCGkO01KU4TYgp9hLWSXVesKiR4OGL/l7isXFOaWCwKRZv7BGJZD1+tzVyEAoEzIIXAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR01FT044.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e18::4d) by HE1EUR01HT096.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e18::280) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Sat, 23 Jan 2021 08:07:55 +0000 Received: from AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM (2a01:111:e400:7e18::41) by HE1EUR01FT044.mail.protection.outlook.com (2a01:111:e400:7e18::107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Sat, 23 Jan 2021 08:07:55 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:DC8FA038B9F931E7F54FBC238D8C0C18718EEBBAD9DE9AB089F5A67C509AB259; UpperCasedChecksum:DDB6C521DC45D237BA7AB37A3B1F2B5B93472BD6523C02BC85A0E742FDF62B3A; SizeAsReceived:7762; Count:47 Received: from AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM ([fe80::7510:8a00:1c00:1147]) by AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM ([fe80::7510:8a00:1c00:1147%5]) with mapi id 15.20.3784.016; Sat, 23 Jan 2021 08:07:54 +0000 Subject: Re: [PATCH][gdb/breakpoint] Fix stepping past non-stmt line-table entries To: Tom de Vries , gdb-patches@sourceware.org References: <20210114132632.GA31266@delia> From: Bernd Edlinger Message-ID: Date: Sat, 23 Jan 2021 09:07:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <20210114132632.GA31266@delia> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TMN: [6YNrFgJzKI0va454slsck28s2smfQ6h+] X-ClientProxiedBy: AM9P195CA0003.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:21f::8) To AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:364::23) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (88.68.3.2) by AM9P195CA0003.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:21f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Sat, 23 Jan 2021 08:07:54 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 47 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: e425d463-6412-48fb-bc84-08d8bf75fc9e X-MS-TrafficTypeDiagnostic: HE1EUR01HT096: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: o7iMwCYZL5Y2yK0vxwepkCUJ8U39LfrUTHZc5bZTj54cSM3+Ukuf3Y0zu8BZSD+Rqkn7pyAT617r4XZMo5Lc9aj6BBdXm1OxZ0Ht1g71bJQot6b1/fG+flaBNMKZnqOU0FyXrAXi8cqQHO1xUwp4rtCgYjQmhoqF2DQ3ChgdP85XsY7k1X/XeSlF/L/S6ihzrGzsvHqCs0f0mwdN2DZtmnYm01lA32YEQk11usUowx7ssZWSHit4wFbA1V7NPYBT X-MS-Exchange-AntiSpam-MessageData: IQkO9VvvqIlBjmX0Hgc8+fdScUkQ/cmtrrZsav+dXODwGfFKsmnzzUSIPs3kPoeIj6GXLRaNBoqSquKwS34pS8YzjYl1mk6wc4aR0suTkAFG1GuxZfWnm+M0RsYM9gT4JBjLJKbqOA4V+mVKOfIWPw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e425d463-6412-48fb-bc84-08d8bf75fc9e X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2021 08:07:54.6122 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: HE1EUR01FT044.eop-EUR01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT096 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 1/14/21 2:26 PM, Tom de Vries wrote: > Hi, > > Consider the test-case small.c: > ... > $ cat -n small.c > 1 __attribute__ ((noinline, noclone)) > 2 int foo (char *c) > 3 { > 4 asm volatile ("" : : "r" (c) : "memory"); > 5 return 1; > 6 } > 7 > 8 int main () > 9 { > 10 char tpl1[20] = "/tmp/test.XXX"; > 11 char tpl2[20] = "/tmp/test.XXX"; > 12 int fd1 = foo (tpl1); > 13 int fd2 = foo (tpl2); > 14 if (fd1 == -1) { > 15 return 1; > 16 } > 17 > 18 return 0; > 19 } > ... > > Compiled with gcc-8 and optimization: > ... > $ gcc-8 -O2 -g small.c > ... > > We step through the calls to foo, but fail to visit line 13: > ... > 12 int fd1 = foo (tpl1); > (gdb) step > foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5 > 5 return 1; > (gdb) step > foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5 > 5 return 1; > (gdb) step > main () at small.c:14 > 14 if (fd1 == -1) { > (gdb) > ... > > This is caused by the following. The calls to foo are implemented by these > insns: > .... > 4003df: 0f 29 04 24 movaps %xmm0,(%rsp) > 4003e3: 0f 29 44 24 20 movaps %xmm0,0x20(%rsp) > 4003e8: e8 03 01 00 00 callq 4004f0 > 4003ed: 48 8d 7c 24 20 lea 0x20(%rsp),%rdi > 4003f2: 89 c2 mov %eax,%edx > 4003f4: e8 f7 00 00 00 callq 4004f0 > 4003f9: 31 c0 xor %eax,%eax > ... > with corresponding line table entries: > ... > INDEX LINE ADDRESS IS-STMT > 8 12 0x00000000004003df Y > 9 10 0x00000000004003df > 10 11 0x00000000004003e3 > 11 12 0x00000000004003e8 > 12 13 0x00000000004003ed > 13 12 0x00000000004003f2 > 14 13 0x00000000004003f4 Y > 15 13 0x00000000004003f4 > 16 14 0x00000000004003f9 Y > 17 14 0x00000000004003f9 > ... > > Once we step out of the call to foo at 4003e8, we land at 4003ed, and gdb > enters process_event_stop_test to figure out what to do. > > That entry has is-stmt=n, so it's not the start of a line, so we don't stop > there. However, we do update ecs->event_thread->current_line to line 13, > because the frame has changed (because we stepped out of the function). > > Next we land at 4003f2. Again the entry has is-stmt=n, so it's not the start > of a line, so we don't stop there. However, because the frame hasn't changed, > we don't update update ecs->event_thread->current_line, so it stays 13. > > Next we land at 4003f4. Now is-stmt=y, so it's the start of a line, and we'd > like to stop here. > > But we don't stop because this test fails: > ... > if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc) > && (ecs->event_thread->current_line != stop_pc_sal.line > || ecs->event_thread->current_symtab != stop_pc_sal.symtab)) > { > ... > because ecs->event_thread->current_line == 13 and stop_pc_sal.line == 13. > > Fix this by resetting ecs->event_thread->current_line to 0 if is-stmt=n and > the frame has changed, such that we have: > ... > 12 int fd1 = foo (tpl1); > (gdb) step > foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5 > 5 return 1; > (gdb) step > main () at small.c:13 > 13 int fd2 = foo (tpl2); > (gdb) > ... > > Tested on x86_64-linux, with gcc-7 and gcc-8. > > Any comments? > I agree that this should be fixed. It is interesting that the small.c example does not miss to step at line 13 if I manually add a nop after the call foo. In this case we are still at line 12, where the call is coming from. I think when we step away from the call instruction we should use the line info from the call statement which is 12 in this example, not the non-stmt line immediately after the call stmt which is 13. find_pc_line can be used to find the line immediately before the current pc when the second parameter is non-zero. So how about this: diff --git a/gdb/infrun.c b/gdb/infrun.c index 7bbfe04..c823586 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -7048,6 +7048,19 @@ struct wait_one_event infrun_debug_printf ("stepped to a different line, but " "it's not the start of a statement"); } + else + { + struct symtab_and_line call_line; + + /* We are returning from a call immediatley before the stop_pc. + Therefore we are stepping away from the call line. */ + call_line = find_pc_line (ecs->event_thread->suspend.stop_pc, 1); + if (call_line.line != 0) + { + stop_pc_sal.line = call_line.line; + stop_pc_sal.symtab = call_line.symtab; + } + } } /* We aren't done stepping. Bernd.