From patchwork Thu Jul 4 04:54:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Buettner X-Patchwork-Id: 33525 Received: (qmail 43099 invoked by alias); 4 Jul 2019 04:55:39 -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 42987 invoked by uid 89); 4 Jul 2019 04:55:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.8 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= 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; Thu, 04 Jul 2019 04:55:36 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5895A3082A8F for ; Thu, 4 Jul 2019 04:55:35 +0000 (UTC) Received: from f30-1.lan (ovpn-117-224.phx2.redhat.com [10.3.117.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2E4DE968BD; Thu, 4 Jul 2019 04:55:35 +0000 (UTC) From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Kevin Buettner Subject: [PATCH v2 1/5] Prefer symtab symbol over minsym for function names in non-contiguous blocks Date: Wed, 3 Jul 2019 21:54:59 -0700 Message-Id: <20190704045503.1250-2-kevinb@redhat.com> In-Reply-To: <20190704045503.1250-1-kevinb@redhat.com> References: <20190704045503.1250-1-kevinb@redhat.com> MIME-Version: 1.0 X-IsSubscribed: yes 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". This comment reads as follows: /* In certain pathological cases, the symtabs give the wrong function (when we are in the first function in a file which is compiled without debugging symbols, the previous function is compiled with debugging symbols, and the "foo.o" symbol that is supposed to tell us where the file with debugging symbols ends has been truncated by ar because it is longer than 15 characters). This also occurs if the user uses asm() to create a function but not stabs for it (in a file compiled with -g). So look in the minimal symbol tables as well, and if it comes up with a larger address for the function use that instead. I don't think this can ever cause any problems; there shouldn't be any minimal symbols in the middle of a function; if this is ever changed many parts of GDB will need to be changed (and we'll create a find_pc_minimal_function or some such). */ In an earlier version of this patch, I had left the code for the pathological case intact, but those who reviwed that patch recommended removing it. So that's what I've done - I've removed it. gdb/ChangeLog: * stack.c (find_frame_funname): Remove code which preferred minsym over symtab sym in "certain pathological cases". --- gdb/stack.c | 71 +++++++++++------------------------------------------ 1 file changed, 15 insertions(+), 56 deletions(-) diff --git a/gdb/stack.c b/gdb/stack.c index b3d113d3b4..e0a7403ec0 100644 --- a/gdb/stack.c +++ b/gdb/stack.c @@ -1135,66 +1135,25 @@ find_frame_funname (struct frame_info *frame, enum language *funlang, func = get_frame_function (frame); if (func) { - /* In certain pathological cases, the symtabs give the wrong - function (when we are in the first function in a file which - is compiled without debugging symbols, the previous function - is compiled with debugging symbols, and the "foo.o" symbol - that is supposed to tell us where the file with debugging - symbols ends has been truncated by ar because it is longer - than 15 characters). This also occurs if the user uses asm() - to create a function but not stabs for it (in a file compiled - with -g). - - So look in the minimal symbol tables as well, and if it comes - up with a larger address for the function use that instead. - I don't think this can ever cause any problems; there - shouldn't be any minimal symbols in the middle of a function; - if this is ever changed many parts of GDB will need to be - changed (and we'll create a find_pc_minimal_function or some - such). */ + const char *print_name = SYMBOL_PRINT_NAME (func); - 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))) - msymbol - = lookup_minimal_symbol_by_pc (get_frame_address_in_block (frame)); - else - memset (&msymbol, 0, sizeof (msymbol)); - - if (msymbol.minsym != NULL - && (BMSYMBOL_VALUE_ADDRESS (msymbol) - > BLOCK_ENTRY_PC (SYMBOL_BLOCK_VALUE (func)))) + *funlang = SYMBOL_LANGUAGE (func); + if (funcp) + *funcp = func; + if (*funlang == language_cplus) { - /* We also don't know anything about the function besides - its address and name. */ - func = 0; - funname.reset (xstrdup (MSYMBOL_PRINT_NAME (msymbol.minsym))); - *funlang = MSYMBOL_LANGUAGE (msymbol.minsym); + /* It seems appropriate to use SYMBOL_PRINT_NAME() here, + to display the demangled name that we already have + stored in the symbol table, but we stored a version + with DMGL_PARAMS turned on, and here we don't want to + display parameters. So remove the parameters. */ + funname = cp_remove_params (print_name); } - else - { - const char *print_name = SYMBOL_PRINT_NAME (func); - *funlang = SYMBOL_LANGUAGE (func); - if (funcp) - *funcp = func; - if (*funlang == language_cplus) - { - /* It seems appropriate to use SYMBOL_PRINT_NAME() here, - to display the demangled name that we already have - stored in the symbol table, but we stored a version - with DMGL_PARAMS turned on, and here we don't want to - display parameters. So remove the parameters. */ - funname = cp_remove_params (print_name); - } - - /* If we didn't hit the C++ case above, set *funname - here. */ - if (funname == NULL) - funname.reset (xstrdup (print_name)); - } + /* If we didn't hit the C++ case above, set *funname + here. */ + if (funname == NULL) + funname.reset (xstrdup (print_name)); } else {