From patchwork Sun May 5 20:04:03 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Buettner X-Patchwork-Id: 32561 Received: (qmail 74616 invoked by alias); 5 May 2019 20:04:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 74608 invoked by uid 89); 5 May 2019 20:04:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_STOCKGEN, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=intact, UD:print.c, print.c, UD:65 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 05 May 2019 20:04:06 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5B397FD45; Sun, 5 May 2019 20:04:04 +0000 (UTC) Received: from f29-4.lan (ovpn-116-84.phx2.redhat.com [10.3.116.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6E9E418AAB; Sun, 5 May 2019 20:04:04 +0000 (UTC) Date: Sun, 5 May 2019 13:04:03 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Eli Zaretskii , simark@simark.ca Subject: Re: The 'cold' function attribute and GDB Message-ID: <20190505130403.56de7f08@f29-4.lan> In-Reply-To: <835zqqmxk9.fsf@gnu.org> References: <83wojaovbp.fsf@gnu.org> <077aee8c-7bef-bad6-a6a1-e69f116cc18b@simark.ca> <20190501195113.69aea752@f30-4.lan> <20190502003849.6759d177@f29-4.lan> <83muk4q3rr.fsf@gnu.org> <20190502112517.64b6fa20@f29-4.lan> <83zho4ofkh.fsf@gnu.org> <20190502121305.111b5fdc@f29-4.lan> <83y33oodv2.fsf@gnu.org> <20190502124509.0d2c546c@f29-4.lan> <83sgtwock8.fsf@gnu.org> <20190502163015.507e652b@f29-4.lan> <835zqqmxk9.fsf@gnu.org> MIME-Version: 1.0 X-IsSubscribed: yes On Sat, 04 May 2019 11:30:14 +0300 Eli Zaretskii wrote: > Do you want me to test some patch? See below. > And why doesn't the GNU/Linux executable have this minimal symbol in > the first place, btw? It turns out that the GNU/Linux executable does have this symbol. The difference is in its placement. The GNU/Linux executable placed the .cold address before that of the entry pc for the function. The windows executable places it after the entry pc. The code mentioned in my earlier analysis prefers to use the minsym only when it's greater than the entry pc. My patch is below. If it works for you and the approach seems sound, I'll work on a test case which doesn't depend on gcc placing the .cold section after the entry pc. - - - Prefer symtab symbol over minsym for function names in discontiguous blocks The discussion on gdb-patches which led to this patch may be found here: https://www.sourceware.org/ml/gdb-patches/2019-05/msg00018.html Here's a brief synopsis/analysis: Eli Zaretskii, while debugging a Windows emacs executable, found that functions comprised of more than one (non-contiguous) address range were not being displayed correctly in a backtrace. This is the example that Eli provided: (gdb) bt #0 0x76a63227 in KERNELBASE!DebugBreak () from C:\Windows\syswow64\KernelBase.dll #1 0x012e7b89 in emacs_abort () at w32fns.c:10768 #2 0x012e1f3b in print_vectorlike.cold () at print.c:1824 #3 0x011d2dec in print_object (obj=, printcharfun=XIL(0), escapeflag=true) at print.c:2150 The function print_vectorlike consists of two address ranges, one of which contains "cold" code which is expected to not execute very often. There is a minimal symbol, print_vectorlike.cold.65, which is the address of the "cold" range. GDB is prefering this minsym over the the name provided by the DWARF info due to some really old code in GDB which handles "certain pathological cases". See the first big block comment in find_frame_funname for more info. I considered removing the code for this corner case entirely, but it seems as though it might still be useful, so I left it intact. That code is already disabled for inline functions. I added a condition which disables it for non-contiguous functions as well. gdb/ChangeLog: * stack.c (find_frame_funname): Disable use of minsym for function name in functions comprised of non-contiguous blocks. --- gdb/stack.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/gdb/stack.c b/gdb/stack.c index e5de10949d..66ba5ab43c 100644 --- a/gdb/stack.c +++ b/gdb/stack.c @@ -1067,9 +1067,18 @@ find_frame_funname (struct frame_info *frame, enum language *funlang, struct bound_minimal_symbol msymbol; - /* Don't attempt to do this for inlined functions, which do not - have a corresponding minimal symbol. */ - if (!block_inlined_p (SYMBOL_BLOCK_VALUE (func))) + /* Don't attempt to do this for two cases: + + 1) Inlined functions, which do not have a corresponding minimal + symbol. + + 2) Functions which are comprised of non-contiguous blocks. + Such functions often contain a minimal symbol for a + "cold" range, i.e. code which is not expected to execute + very often. It is incorrect to use the minimal symbol + associated with this range. */ + if (!block_inlined_p (SYMBOL_BLOCK_VALUE (func)) + && BLOCK_CONTIGUOUS_P (SYMBOL_BLOCK_VALUE (func))) msymbol = lookup_minimal_symbol_by_pc (get_frame_address_in_block (frame)); else