From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Y9fAGOM0tmCSXgAAWB0awg (envelope-from ) for ; Tue, 01 Jun 2021 09:23:47 -0400 Received: by simark.ca (Postfix, from userid 112) id 552F91F163; Tue, 1 Jun 2021 09:23:47 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,URIBL_BLOCKED autolearn=ham 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 5A0B51E813 for ; Tue, 1 Jun 2021 09:23:46 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E4725394843F; Tue, 1 Jun 2021 13:23:45 +0000 (GMT) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 5BE013846078 for ; Tue, 1 Jun 2021 13:23:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5BE013846078 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 6C66F2192E; Tue, 1 Jun 2021 13:23:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1622553822; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MrDTPEgTWSM8RpuMYeX+gk9WABy0br5zLyISngl5FkQ=; b=gR7cmI/bpDxT7qa62Ddu+cPpGlx6HWbAje+IDoyNR32ZO/GkzzfXqTZgSw1C/hzGRYg8k0 29yTpoo4pZIkgDQR5oq8kFCSFZIcG3aGEjKF68o5PEbBTNaeUxQP4DfZBLxXfyzG5mUbPh xsSyMsEtci9DvMgQTsH1XqLioMjQnu4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1622553822; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MrDTPEgTWSM8RpuMYeX+gk9WABy0br5zLyISngl5FkQ=; b=Q4SFAVpX1h/1Tr1USgdF39VPpgxq/nYhlc4ozkVlvyfGwdBUWStyPvovL9go21yse9WxfD NtRvb935rog+HtAA== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 48FE5118DD; Tue, 1 Jun 2021 13:23:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1622553822; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MrDTPEgTWSM8RpuMYeX+gk9WABy0br5zLyISngl5FkQ=; b=gR7cmI/bpDxT7qa62Ddu+cPpGlx6HWbAje+IDoyNR32ZO/GkzzfXqTZgSw1C/hzGRYg8k0 29yTpoo4pZIkgDQR5oq8kFCSFZIcG3aGEjKF68o5PEbBTNaeUxQP4DfZBLxXfyzG5mUbPh xsSyMsEtci9DvMgQTsH1XqLioMjQnu4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1622553822; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MrDTPEgTWSM8RpuMYeX+gk9WABy0br5zLyISngl5FkQ=; b=Q4SFAVpX1h/1Tr1USgdF39VPpgxq/nYhlc4ozkVlvyfGwdBUWStyPvovL9go21yse9WxfD NtRvb935rog+HtAA== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id TyOmEN40tmBbBAAALh3uQQ (envelope-from ); Tue, 01 Jun 2021 13:23:42 +0000 Subject: Re: [PATCH][gdb/symtab] Ignore cold clones To: Bernd Edlinger , Simon Marchi , gdb-patches@sourceware.org References: <20210531141512.GA3181@delia> <5af89971-6072-bfd3-2bc8-c0255770fd70@polymtl.ca> From: Tom de Vries Message-ID: Date: Tue, 1 Jun 2021 15:23:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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? Yes (as you found out by now). And looking at the DW_AT_producer it's generated by gcc-9 flto: ... DW_AT_producer : GNU C++14 9.0.0 20180925 (experimental) [trunk revision 259470] -mtune=generic -march=x86-64 -g -O2 -fno-PIE -flto=jobserver -frandom-seed=1 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables ... > I never saw this kind of mangled symbol. > > 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. > Yeah, good point. Well, there's nvptx for example, but that one doesn't have upstream gdb support. Anyway, it might be that this is dealt with somehow in the demangler, I'm not sure. So I don't think it makes sense to try to fix this until we see proof that it's actually broken. Thanks, - Tom