From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DPHVFzTDtWBpUwAAWB0awg (envelope-from ) for ; Tue, 01 Jun 2021 01:18:44 -0400 Received: by simark.ca (Postfix, from userid 112) id 53AE41F163; Tue, 1 Jun 2021 01:18:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=FORGED_MUA_MOZILLA, FREEMAIL_FROM,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [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 B19451E813 for ; Tue, 1 Jun 2021 01:18:42 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9B793383F40D; Tue, 1 Jun 2021 05:18:41 +0000 (GMT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-oln040092074020.outbound.protection.outlook.com [40.92.74.20]) by sourceware.org (Postfix) with ESMTPS id C1F4C384B801 for ; Tue, 1 Jun 2021 05:18:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C1F4C384B801 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=oWidwhvFJYhE9Fd+Ye1eaxMkec2JgOx9qvpkgA1r++9Ch46L2T7UVbl85sUwkguohtf9Wr2jlkVVN35JPLBUOfPa5SoVAFKDSTNRRpCJ3A9lHMC03SuB2Zu3/Gy8smO/mw25p6x79UkfyGJrSkukVnCmvh7J8tFZ9vCMPLfLlO8LGPhsYc9c5GLOagGgOQK19t6tNMlQK1Tks4kMTqR68rw7zb5kaNItYz+NsNheh9275hSJsdLgOEhRVeyup90x717pV1xs11wtkp9pQ1DDEWglnmNbUDUUbmZXSGB9YeqC1GAbe0qSRqcWBVpo+65aNS0Gli/Fxc+ktQeffXQ1kg== 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=ErxcofPCLEasayKUzDA6QWZUWKCKfXqpdomvE7j6Gao=; b=cAJJbt5O7WzBlXTEdBQBKhfCEOqqWCOyPBjL00SJH9Rq7HYnVKoWasOTfrHwb3J08Wi7qo2AJqziAJwmu1CENcRUGnfbe80mDKoIOZg7p12q+HOJsxCrEshAqSLO9KVhVXNw/ZtUY2o12drgDXvroui7FK8O2BHHOdQ6KLfQbAdYyp0gjPYVmkbD+ZYZAhstmPa2O6CstDQ5B8j/ZgeF+9o8eWkNMumUP2b86A+00l4qOKKcHh8DZv9rFHwPMpi9hQpyCidy8Rr0X4d+un3w6ylTNRWaPzePBeF6IdfKil3cKBgEYvWi1kZiTOu53/eA5+R4Sz6rUY6XSMt4Gtt//A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR04FT052.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::43) by HE1EUR04HT225.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::410) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.28; Tue, 1 Jun 2021 05:18:35 +0000 Received: from AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM (2a01:111:e400:7e0d::45) by HE1EUR04FT052.mail.protection.outlook.com (2a01:111:e400:7e0d::297) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.28 via Frontend Transport; Tue, 1 Jun 2021 05:18:35 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:FE88DA473725B8FC240E67B3F580E5576D2CD29859BCE7A21B5ABBE1B302AEA3; UpperCasedChecksum:95D3C9B9168DC32136A9780B0E4D797DB25E63E2811F98FD01A1FA25F7ACE518; SizeAsReceived:8859; Count:47 Received: from AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM ([fe80::ad12:6a2c:b949:f65d]) by AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM ([fe80::ad12:6a2c:b949:f65d%5]) with mapi id 15.20.4173.030; Tue, 1 Jun 2021 05:18:35 +0000 Subject: Re: [PATCH][gdb/symtab] Ignore cold clones From: Bernd Edlinger To: Tom de Vries , Simon Marchi , gdb-patches@sourceware.org References: <20210531141512.GA3181@delia> <5af89971-6072-bfd3-2bc8-c0255770fd70@polymtl.ca> Message-ID: Date: Tue, 1 Jun 2021 07:18:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TMN: [HlU3Gp4uo8GfcgcpMMOxYIMud64cp3MV] X-ClientProxiedBy: FR0P281CA0046.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:48::23) To AM8PR10MB4708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:364::23) X-Microsoft-Original-Message-ID: <0e45b133-a153-81d6-ea89-ca2462bd233e@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (84.57.61.94) by FR0P281CA0046.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:48::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.10 via Frontend Transport; Tue, 1 Jun 2021 05:18:34 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 47 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: d609e98e-ee96-4e31-db62-08d924bcb43e X-MS-TrafficTypeDiagnostic: HE1EUR04HT225: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8GRfPTib9VPUPRsBqOcDr/VxkFWkp6k7DJeiy9UaBjB/Os51J4yTeWl2Z0ewQVQrqloXGGVPPueb6fPTTTxZqBTRjmWLGQs2xfGwVR6VVxhrgCNqg5TbGsR0jtJ3i6bOoGloGqNu1grp1CGpuKVcS+X/dWSRX/6OIJWhGBFOralQrbg/zrwfManuPmOSdTbDBV2sdLXC+eG/OVL5SrREr+oXyEQ358CIeVup+zxLTkgBoi4phK0+PUUGegkBUEr2AmgbMNezUol5iS3YrFBf6VomYhLT941pEO1FPc4I8yzSTTpx2lhqPAAz0uwGpt48RDub0ZLgIoLFNlW7eOkEHtw1NwVqVNiCSiCVGbWyh9CQJMpYtcBXOHUImRBjmTzY8Xw7Pj1BPYhiZGl3Y3J7tKmioIRGJPNHtu8/r91xZqFHK7m9mvJehcx4TI9knmUQx+emIYdBibuieGH+/LCwYg== X-MS-Exchange-AntiSpam-MessageData: bem3Qx8p7F+ByZz/FkUxwEzEvkqqgoRcA72Yg1EtcVr9qoPDz53YPNdJofIfQeOMOEKW3ZPpvtfEVwfN0uuFTwPobwuHfPTREP/1F1fjBX2eqnfnz0ENKqmj3Xd4NDQtwSuXfsaN3RqoN5uS1Z0Jkg== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d609e98e-ee96-4e31-db62-08d924bcb43e X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2021 05:18:35.7415 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: HE1EUR04FT052.eop-eur04.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: HE1EUR04HT225 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 5/31/21 6:54 PM, Bernd Edlinger wrote: > On 5/31/21 4:59 PM, Tom de Vries wrote: >> On 5/31/21 4:26 PM, Simon Marchi wrote: >>> On 2021-05-31 10:15 a.m., Tom de Vries wrote: >>>> Hi, >>>> >>>> Consider the test-case contained in this patch, compiled for c using gcc-10: >>>> ... >>>> $ gcc-10 -x c src/gdb/testsuite/gdb.cp/cold-clone.cc -O2 -g -Wall -Wextra >>>> ... >>>> >>>> When setting a breakpoint on foo, we get one breakpoint location: >>>> ... >>>> $ gdb -q -batch a.out -ex "b foo" >>>> Breakpoint 1 at 0x400560: file cold-clone.cc, line 28. >>>> ... >>>> >>>> However, when we compile for c++ instead, we get two breakpoint locations: >>>> ... >>>> $ gdb -q -batch a.out -ex "b foo" -ex "info break" >>>> Breakpoint 1 at 0x400430: foo. (2 locations) >>>> Num Type Disp Enb Address What >>>> 1 breakpoint keep y >>>> 1.1 y 0x0000000000400430 in foo() at cold-clone.cc:30 >>>> 1.2 y 0x0000000000400560 in foo() at cold-clone.cc:28 >>>> ... >>>> >>>> The additional breakpoint location at 0x400430 corresponds to the cold clone: >>>> ... >>>> $ nm a.out | grep foo >>>> 0000000000400560 t _ZL3foov >>>> 0000000000400430 t _ZL3foov.cold >>>> ... >>>> which demangled looks like this: >>>> ... >>>> $ nm -C a.out | grep foo >>>> 0000000000400560 t foo() >>>> 0000000000400430 t foo() [clone .cold] >>>> ... >>>> >>>> [ Or, in the case of the cc1 mentioned in PR23710: >>>> ... >>>> $ nm cc1 | grep do_rpo_vn.*cold >>>> 000000000058659d t \ >>>> _ZL9do_rpo_vnP8functionP8edge_defP11bitmap_headbb.cold.138 >>>> $ nm -C cc1 | grep do_rpo_vn.*cold >>>> 000000000058659d t \ >>>> do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool) [clone .cold.138] >>>> ... ] >>>> >>>> The cold clone is a part of the function that is split off from the rest of >>>> the function because it's considered cold (not frequently executed). So while >>>> the symbol points to code that is part of a function, it doesn't point to a >>>> function entry, so the desirable behaviour for "break foo" is to ignore this >>>> symbol. >>>> >>>> When compiling for c, the symbol "foo.cold" is entered as minimal symbol >>>> with the search name "foo.cold", and the lookup using "foo" fails to find that >>>> symbol. >>>> >>>> But when compiling for c++, the symbol "foo.cold" is entered as minimal symbol >>>> with both the mangled and demangled name, and for the demangled name >>>> "foo() [clone .cold]" we get the search name "foo" (because >>>> cp_search_name_hash stops hashing at '('), and the lookup using "foo" succeeds. >>>> >>>> Fix this by recognizing the cold clone suffix and returning false for such a >>>> minimal symbol in msymbol_is_function. >>>> >>>> Tested on x86_64-linux. >>>> >>>> Any comments? >>> >>> Is this related to >>> >>> https://sourceware.org/pipermail/gdb-patches/2021-May/179371.html >>> >> >> Yes, it looks like both attempt to fix the same PR, thanks for the pointer. >> >> At first glance, that one doesn't handle symbol >> "_ZL9do_rpo_vnP8functionP8edge_defP11bitmap_headbb.cold.138". >> > > Is this symbol from gcc? > I never saw this kind of mangled symbol. > So, I did a gcc lto-bootstrap over night with the current trunk version, and got these symbols in cc1: $ nm cc1|grep do_rpo_vn 0000000000fb9a70 T _Z9do_rpo_vnP8functionP8edge_defP11bitmap_head 0000000000fb7a40 t _ZL9do_rpo_vnP8functionP8edge_defP11bitmap_headbb.lto_priv.0 0000000000719052 t _ZL9do_rpo_vnP8functionP8edge_defP11bitmap_headbb.lto_priv.0.cold does your patch handle these? Bernd. > TBH, I was not sure if I should handle foo$cold or __foo_cold. > In theory there may be targets where the assembler does not like ".", > then gcc would emit foo$cold > If neither "." nor "$" is acceptable then gcc would emit __foo_cold > but I was not sure if such targets do really exist. > > > Bernd. > >> Another difference seems to be how the cold clone status is determined: >> - this patch uses the demangled name, and treats finding the .cold >> string (used in a specific way) as proof >> - Bernd's patch uses the mangled name, and treats finding the .cold >> string as a hint, and proceeds to find the corresponding function >> entry symbol to proof it >> >> [ FWIW, that patch mentions it fixes 77f2120b200 ("Don't drop static >> function bp locations w/o debug info"), but the PR did exist before that >> commit, that commit just made it more frequent. ] >> >> Thanks, >> - Tom >>