From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-oln040092066063.outbound.protection.outlook.com [40.92.66.63]) by sourceware.org (Postfix) with ESMTPS id 15DCF396B43F for ; Wed, 11 Aug 2021 05:27:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15DCF396B43F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hotmail.de ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lbsowGfJW3pEUnVcl5Yhk1KbT9kNFDxSw1Gf3Y5q2dnLbU5h9xDlwgD63N7sYYqBZ1aEmh4SA1/X+4z+b9Yrf4cLQFzmoqcv+BWF9ckZjwtglrQ2++4VsJ39goBhWmwNBMUMyU5gKQB5fEXNZVQPoePx3tp5cqzMOXWrj4GpmF0q/KyK0dm9Z9qkoViMoH/QW/FY/tdfyxyhOPR/6Mu2OHrPAWujPT689RaKltwMKijniHf7jybUxULAwV7I+JPu/f23cy56ylJn95ID2VmoWRtkYiVbX+9Ufl6nA+lMPuLsibnuwoWyyvZKMI8ujLJ1AgbUh7YrzJ9fJkEEvumBuw== 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=Heauhzvlm6zWp5t1Q6NU5cEK4wTX9GidXPfoRBTaro4=; b=oJlOS23z9nL8kCca4yTCN+aYAgbX2K0Wh+/9BnJ4A5E+ZbkUQX+0NpyjKX/sCKdUBI7qckosDmxed+Bd32aW6/Qss67fD9W6IfyY9vax9PPypoWXK6ueRwDcM0wuQtdHtqAwsNrYrnr7rMyK+R361Jq10d434IvT00nXrFrWUIWhUngBW2UFisLRX+JD8vqErs0dofrqeOCMJGU6cdgGHQPbMVKVP7OnNId8i7coo9LQeizVTthil/Qv7FIB/ruhSB+KHjtjEBqMexfJuEzH/vyGeQ5jSeib3DyC1cu6VEinqE/YQ+JXz7qpOxHBwBc/dfRV0iSgUz+3A1OmvQNy0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VE1EUR01FT014.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e19::47) by VE1EUR01HT051.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e19::385) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16; Wed, 11 Aug 2021 05:27:07 +0000 Received: from AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM (2a01:111:e400:7e19::41) by VE1EUR01FT014.mail.protection.outlook.com (2a01:111:e400:7e19::219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.16 via Frontend Transport; Wed, 11 Aug 2021 05:27:07 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:CDE1CBB03C510417C3B58C9BB089A03C24D12845AB7571010127E86A22CE0EB2; UpperCasedChecksum:FD4E6EBF223C80EE74107434A594C80095E9277C2455565055BD62684CE82875; SizeAsReceived:8056; Count:48 Received: from AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM ([fe80::dc99:4f1e:bd14:2597]) by AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM ([fe80::dc99:4f1e:bd14:2597%7]) with mapi id 15.20.4394.025; Wed, 11 Aug 2021 05:27:07 +0000 Subject: Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org, Richard Biener , Arnaud Charlet References: <1886121.usQuhbGJ8B@arcturus> <1703105.VLH7GnMWUR@arcturus> From: Bernd Edlinger Message-ID: Date: Wed, 11 Aug 2021 07:27:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <1703105.VLH7GnMWUR@arcturus> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TMN: [hjJebLaVAVDDD7bhWbDN9dic/+j/WCVU] X-ClientProxiedBy: AM0PR06CA0121.eurprd06.prod.outlook.com (2603:10a6:208:ab::26) To AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:364::23) X-Microsoft-Original-Message-ID: <27174800-a52f-d9e3-520f-e297bc12b581@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (88.76.118.196) by AM0PR06CA0121.eurprd06.prod.outlook.com (2603:10a6:208:ab::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.15 via Frontend Transport; Wed, 11 Aug 2021 05:27:06 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 8c47f165-7933-49e4-7aa6-08d95c88a8d4 X-MS-TrafficTypeDiagnostic: VE1EUR01HT051: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: m2N4R0cWxVNW+d1odAa4hZpnEKH06MKMvuGigbTzuJRgJKcWmB52krYtCHCw3NLa9RdcF8YWfwhaU2rDvypV9sR+zrb4Fo9Qhse8lUrcvzbakSIj1xQSd3S826k3h3e/VEy7TnaYCCoar2V79q3lkDInDCjQmIleon4zdCbmoxfHgWBg1eF36JvWQsdQpt48AV7ejnRbYCk9Hy53zpw0lIdAJ4qvBrqWiIM8PYGtNo0vw+S1aNCfRaqx54dMUhgbG7J288ZPl5qDErYE0KI26pFBDp8uVyG13ex1J6xK/d1iC5JwqGCl7SVN2u7SHztPM7V5jNJC0b2+mA+9UBTMOV6deD7LNQ0RIG1UDZqsIjP8avpZN1DlK3O7LNXdxbg3mSA4U+ATdx4I0G9xmzcx0Bnx57+Qipmv2xAfea52nTI7zpfnjCPZutt2T13jLaGNHQdaMfdBAVraL5UClCn90wP+A0/qTCUWJ7wr+Ct6Na8= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 44FqccQRlsemcxKQS0kHT4O1/OC7iGxvudiG9RzjVEBIqigK8FS/65YglrFiVkR6QW/9a1YTEnaCr5wGcyU7bKdRMvBmnEuo8o2qCQrkR0xs4QapD0q4X561k9DPiioZ0BNJNF9D1q/4LuScw9rZUA== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c47f165-7933-49e4-7aa6-08d95c88a8d4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2021 05:27:07.2279 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: VE1EUR01FT014.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: VE1EUR01HT051 X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, FORGED_MUA_MOZILLA, FREEMAIL_FROM, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 05:27:19 -0000 On 8/10/21 10:56 PM, Eric Botcazou wrote: >> Ah, thanks, I tried it but the defs__struct1IP function has >> DECL_IGNORED_P = false when I build it with -gnatD. >> >> So that would not be affected by setting DECL_SOURCE_LOCATION to >> UNKNOWN_LOCATION as done in the proposed patch, because that is only >> done for functions with DECL_IGNORED_P = true. > > Ouch, I should have checked it myself... Thanks for doing the investigation. > no problem. >> Then we have ordinary functions with DECL_IGNORED_P = false, >> but they are morphed into a thunk calling a similar looking function >> and the thunk has now DECL_IGNORED_P = true, and all debug info >> removed, except the DECL_SOURCE_LOCATION. To make this even worse, >> the similar looking function is inlined into the thunk again, and >> all debug info is again stripped away. >> >> And when this happens it is desirable to at least see the source line where >> the original function was declared. >> >> >> As an example, please consider this test case: >> >> $ cat test.ads >> package test is >> >> type Func_Ptr is access function (X : Integer) return Integer; >> >> function Test1 (X : Integer) return Integer; >> function Test2 (X : Integer) return Integer; >> function DoIt (X : Integer; Func : Func_Ptr) return Integer; >> >> end test; >> $ cat test.ads >> package test is >> >> type Func_Ptr is access function (X : Integer) return Integer; >> >> function Test1 (X : Integer) return Integer; >> function Test2 (X : Integer) return Integer; >> function DoIt (X : Integer; Func : Func_Ptr) return Integer; >> >> end test; >> >> $ cat test.adb >> package body test is >> >> function Test1 (X : Integer) return Integer is >> begin >> return X; >> end Test1; >> >> function Test2 (X : Integer) return Integer is >> begin >> return X; >> end Test2; >> >> function DoIt (X : Integer; Func : Func_Ptr) return Integer is >> begin >> return Func (X); >> end DoIt; >> >> end test; >> >> $ cat main.adb >> with Ada.Text_IO; use Ada.Text_IO; >> with test; use test; >> >> procedure Main is >> >> X : Integer := 7; >> Y : Integer := DoIt (X, Test1'Access); >> Z : Integer := DoIt (X, Test2'Access); >> >> begin >> Put_Line (X'Img & " " & Y'Img & " " & Z'Img); >> end Main; >> >> $ gnatmake -f -g -O2 main.adb -save-temp -fdump-tree-all-lineno >> >> Now Test1 and Test2 are ordinary functions, but Test2 ends up as >> DECL_IGNORED_P = true, that happens between test.adb.052t.local-fnsummary2 >> and test.adb.092t.fixup_cfg3: > > Ouch (bis). Quite unexpected that DECL_IGNORED_P is set out of nowhere. It's > Identical Code Folding which turns Test2 into a thunk? > Yes, the identical functions trigger this folding. Originally I discovered this when I wanted to debug the arm back-end, where we have several identical functions: static bool arm_align_anon_bitfield (void) { return TARGET_AAPCS_BASED; } [...] static bool arm_cxx_guard_mask_bit (void) { return TARGET_AAPCS_BASED; } the second one had no line numbers, but since it was not at the beginning of the assembly gdb did show a totally unrelated line. In general I can say that debugging optimized code is not a very pleasant experience. But this issue happens only rarely, while another issue is much more dominant. You will probably see it quite often while debugging the gcc middle end that stepping over inline functions does not work right, one often steps over some code, and ends up in the tree_check inline function. That's because of an ambiguity in the dwarf debug info of inline ranges. It does not have the view number where the inline range ends exactly, but only the PC. I have been working on some gdb patches to work around the problem, but they are stuck unfortunately :-( "Improve debugging of optimized code" https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html >> in test.adb.052t.local-fnsummary2 we have: >> >> integer test.test1 (integer x) >> { >> [local count: 1073741824]: >> [test.adb:5:7] return x_1(D); >> >> } >> >> and >> >> integer test.test2 (integer x) >> { >> [local count: 1073741824]: >> [test.adb:10:7] return x_1(D); >> >> } >> >> >> but in test.adb.092t.fixup_cfg3 >> >> we have >> >> integer test.test1 (integer x) >> { >> [local count: 1073741824]: >> [test.adb:5:7] return x_1(D); >> >> } >> >> and >> >> integer test.test2 (integer x) >> { >> integer D.4674; >> integer retval.5; >> integer _4; >> >> [local count: 1073741824]: >> # DEBUG x => x_1(D) >> _4 = x_1(D); >> # DEBUG x => NULL >> retval.5_2 = _4; >> return retval.5_2; >> >> } >> >> >> the line numbers are gone, and the function has DECL_IGNORED_P, >> but still a useful DECL_SOURCE_LOCATION, I don't know >> where the DECL_SOURCE_LOCATION can be seen in the dump files, >> but from debugging this effect, I know that quite well. >> >> This second effect is why as a special case DECL_IGNORED_P functions >> with valid looking DECL_SOURCE_LOCATION have now a .loc statement, >> because that is less surprising to a user than having no line numbers >> at all here. > > OK, thanks for the explanation, the patch is OK then. > Thank You very much, I will push it now. Bernd.