From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068029.outbound.protection.outlook.com [40.92.68.29]) by sourceware.org (Postfix) with ESMTPS id 20A413871029 for ; Mon, 16 Mar 2020 22:37:13 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SXc741HQyoV+gdsNPZjBQLlbZwzzLFaV/ttr0hHjQO3HJ8+7jWMm92YpUV2/4NWvlSBve5FlGG1/ht/Mx5V5I2fVVVc/Z10O2p8l2nC7vJhuFQMTGjmgPwsnhEoH83O3XfdNc08G2YS4J6SKluyN5e1yvbEKcZfLTyF7gGKkyL2W3fGpni562BPLLHZ03aGJpnoB14n5w58JLJEFgzDnt21qpfHB/A3ivZ62ISz5q5U8x6NJoDgsW5uGT216PCIlaEVYJ2DHUuJjQgL+eeG+fVQ3iF+qfjrQFQtEkTH5m3Cq13Zg3auVLiNFbWorWVJq+SLIH5kLxg3a3ott/IHEYg== 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=xiK04rmmAqO2Q6qnxFaVTijg7ZWBRPgMbOhUsdveLDc=; b=PzM3vj2bByV9LxGVfCPZBZmJr+oM9K1Bx3ipT+8Tz2a47GNR5pPu+ph8bJ88IpTf+0iE/0N4ZSQXT3xNfviogckccgsbxi+HdHLCH5Y8i+diauOhlot0Torj+hKvNaGY8Fp5kee1vVowFOKCul5WMgrQ1knrU1MqZdoFj+s/dsp8PWr9X0f4AQYYWBD1fcLM5UUjM9a26F1QJr3XxdM0dZtQI4sxrYAs9zbLF+iS1q9c5bMexSRv9geSZHxcKds8dRvV5pZ5eDtOXZXKPQc5zkwag+lvwUzNR9VyTF23b6wLwqxoXeUDaCwI+jgxsppZPmum7eNGfbrbnb158a0uVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hotmail.de; dmarc=pass action=none header.from=hotmail.de; dkim=pass header.d=hotmail.de; arc=none Received: from AM5EUR02FT054.eop-EUR02.prod.protection.outlook.com (2a01:111:e400:7e1c::3a) by AM5EUR02HT120.eop-EUR02.prod.protection.outlook.com (2a01:111:e400:7e1c::337) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Mon, 16 Mar 2020 22:37:11 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.152.8.59) by AM5EUR02FT054.mail.protection.outlook.com (10.152.8.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Mon, 16 Mar 2020 22:37:11 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:E39ADADB1E2515486A7FC5DB026F03AA2468D475C22633B3BD625915D24453C3; UpperCasedChecksum:AEF2FD35A048930C03CF8975E2C411BA6161E3819E8B9A5878B29D85F7FFEFCB; SizeAsReceived:8103; Count:50 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd%6]) with mapi id 15.20.2814.021; Mon, 16 Mar 2020 22:37:10 +0000 Subject: Re: [PATCHv2 2/2] gdb: Add support for tracking the DWARF line table is-stmt field To: Tom Tromey , Andrew Burgess Cc: gdb-patches@sourceware.org References: <87d09c3tmu.fsf@tromey.com> From: Bernd Edlinger Message-ID: Date: Mon, 16 Mar 2020 23:37:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <87d09c3tmu.fsf@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0020.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::7) To AM6PR03MB5170.eurprd03.prod.outlook.com (2603:10a6:20b:ca::23) X-Microsoft-Original-Message-ID: <5812b0b7-e69e-81c9-fce3-d45bc8c1c83b@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by FR2P281CA0020.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.21 via Frontend Transport; Mon, 16 Mar 2020 22:37:09 +0000 X-Microsoft-Original-Message-ID: <5812b0b7-e69e-81c9-fce3-d45bc8c1c83b@hotmail.de> X-TMN: [ykNX7Fz3xULIOz+SiGaDYY5JApN9Sf3I] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 50 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: d588ba19-ccf3-4807-811f-08d7c9fa9077 X-MS-TrafficTypeDiagnostic: AM5EUR02HT120: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: RA7sGZ6IWPfU23i9QUtcSj5MJKUnUQ5tT7s9G3Dz9E3dO4pBRC626ktPwzWqGyOVujFfIGkjPRlz7zUqjsbucuJoyt871K11pb4K7dlij6odaoIcAQMlfI1I01yADOUdYTBAtQimfhNlcBL5iYDYvjsYsPx7qByIXZedYSjUY4qx3Xgd9t2z7meVKJabyx+C X-MS-Exchange-AntiSpam-MessageData: tzRDsouejrRwZ7ZFaU+FyCuhgHH+B0p5gbwIMQ/36zudYXpIrPfp9a2loBQGXiBkbxRupAPCb9daP5daftd6B48uP5fTaPHamoI8lVUwskYhy9nwwHpME6NKg5QuEd00t+LrsCs18b3/32/prDtfbw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d588ba19-ccf3-4807-811f-08d7c9fa9077 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2020 22:37:10.4139 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT120 X-Spam-Status: No, score=2.3 required=5.0 tests=FORGED_MUA_MOZILLA, FREEMAIL_FROM, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Mon, 16 Mar 2020 22:37:15 -0000 On 3/16/20 9:57 PM, Tom Tromey wrote: > Hi. > > This particular hunk causes a regression on an internal test case for a > RISC-V target: > > Andrew> + /* If we have a duplicate for the previous entry then ignore the new > Andrew> + entry, except, if the new entry is setting the is_stmt flag, then > Andrew> + ensure the previous entry respects the new setting. */ > Andrew> + e = subfile->line_vector->item + subfile->line_vector->nitems - 1; > Andrew> + if (e->line == line && e->pc == pc) > Andrew> + { > Andrew> + if (is_stmt && !e->is_stmt) > Andrew> + e->is_stmt = 1; > Andrew> + return; > Andrew> + } > I don't think this whole if statement is really needed. I looks more sane this way, but everything seems to work also without. > Now, I'm not 100% certain that this is a "true" regression. The test > case in question already has a large number of XFAILs for various > targets, because in practice gdb reports different stop locations for > different compilers. > > It's just 2 short files so I can share it here: > > /* r.c */ > #include "r.h" > > int > main () > { > callee (); > } > > /* r.h */ > int counter = 42; > > inline void > callee () { > counter = 0; /* break here */ > } > > When I look at this with readelf I see: > > $ readelf --debug-dump=decodedline ./r > Contents of the .debug_line section: > > r.c: > File name Line number Starting address View Stmt > r.c 6 0x80000042 x > r.c 7 0x80000042 1 x > > r.h: > r.h 6 0x80000042 2 x > r.h 6 0x80000042 3 > > r.c: > r.c 8 0x8000004a 4 > r.c 8 0x8000004e 5 > > I can send an executable if you want. > > If I run gdb on the resulting program and "break r.h:6", before the > is-statement patch it reports r.h:6, but afterward it says: > > (gdb) b r.h:6 > Breakpoint 1 at 0x8000004a: file r.c, line 8. > > Backing out the hunk in question up above is enough to fix the problem. > > What is happening is that gdb is no longer recognizing the special > prologue rule in skip_prologue_sal: > > /* For languages other than assembly, treat two consecutive line > entries at the same address as a zero-instruction prologue. > The GNU assembler emits separate line notes for each instruction > in a multi-instruction macro, but compilers generally will not > do this. */ > > TBH this has always seemed like a big hack, at least in the DWARF era. > But, I suppose it's a hack we continue to need, at least until GCC emits > proper prologue end notes. > > Just removing the "return" is enough to make it work for me. I didn't > try a real test run, though. > > I'd appreciate any thoughts you have on this. > > thanks, > Tom >