From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32344 invoked by alias); 10 Mar 2014 21:43:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32331 invoked by uid 89); 10 Mar 2014 21:42:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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; Mon, 10 Mar 2014 21:42:58 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2ALgvUp012877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 17:42:57 -0400 Received: from host2.jankratochvil.net (ovpn-116-86.ams2.redhat.com [10.36.116.86]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2ALgqdS011233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Mar 2014 17:42:55 -0400 Date: Mon, 10 Mar 2014 21:43:00 -0000 From: Jan Kratochvil To: Markus Metzger Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] btrace: avoid symbol lookup Message-ID: <20140310214252.GA3105@host2.jankratochvil.net> References: <1394182665-14164-1-git-send-email-markus.t.metzger@intel.com> <1394182665-14164-3-git-send-email-markus.t.metzger@intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <1394182665-14164-3-git-send-email-markus.t.metzger@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00250.txt.bz2 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2493 On Fri, 07 Mar 2014 09:57:45 +0100, Markus Metzger wrote: > --- a/gdb/btrace.c > +++ b/gdb/btrace.c > @@ -451,13 +451,17 @@ ftrace_update_function (struct gdbarch *gdbarch, > struct symbol *fun; > struct btrace_insn *last; > > - /* Try to determine the function we're in. We use both types of symbols > - to avoid surprises when we sometimes get a full symbol and sometimes > - only a minimal symbol. */ > - fun = find_pc_function (pc); > + /* Try to determine the function we're in. */ > bmfun = lookup_minimal_symbol_by_pc (pc); > mfun = bmfun.minsym; > > + /* We only lookup the symbol in the debug information if we have not found > + a minimal symbol. This avoids the expensive lookup for globally visible > + symbols. */ > + fun = NULL; > + if (mfun == NULL) > + fun = find_pc_function (pc); > + > if (fun == NULL && mfun == NULL) > DEBUG_FTRACE ("no symbol at %s", core_addr_to_string_nz (pc)); > [...] Behavior after the change is not the same. DWARF functions symbols can span over discontiguous ranges with DW_AT_ranges but their corresponding ELF function symbols cannot, therefore those are just some approximation. Testcase gdb.dwarf2/dw2-objfile-overlap.exp tests such a case, from: https://sourceware.org/ml/gdb-patches/2011-11/msg00166.html For address of symbol "inner": * find_pc_function finds DWARF symbol "inner" * lookup_minimal_symbol_by_pc finds ELF symbol "outer_inner" In few Fedora 20 x86_64 -O2 -g built libraries I have not found any DW_TAG_subprogram using DW_AT_ranges, only DW_TAG_inlined_subroutine use DW_AT_ranges. But that is more a limitation of gcc, other compilers may produce DW_TAG_subprogram using DW_AT_ranges with overlapping function parts. Inlined functions are found by neither find_pc_function nor lookup_minimal_symbol_by_pc (block_containing_function (block_for_pc ()) finds inlined function). Not sure if it is not a bug of find_pc_function but that is off-topic here. I do not think it will be hit in real world cases. GDB would need some better abstraction of the symbol kinds to be more systematic in what it outputs. It would be good to know how much it helps your usecase as it is not a fully clean/transparent change. Thanks, Jan set confirm no set trace-commands file gdb.dwarf2/dw2-objfile-overlap-outer.x add-symbol-file gdb.dwarf2/dw2-objfile-overlap-inner.x outer_inner info sym inner -> find_pc_function "inner". lookup_minimal_symbol_by_pc "outer_inner". --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=1 Content-length: 934 diff --git a/gdb/printcmd.c b/gdb/printcmd.c index 87b1448..f1517d2 100644 --- a/gdb/printcmd.c +++ b/gdb/printcmd.c @@ -1107,6 +1107,27 @@ sym_info (char *arg, int from_tty) error_no_arg (_("address")); addr = parse_and_eval_address (arg); + +{ +struct symbol *sym=find_pc_function (addr); +if (sym) { + printf_filtered ("find_pc_function \""); + fprintf_symbol_filtered (gdb_stdout, SYMBOL_PRINT_NAME (sym), + current_language->la_language, DMGL_ANSI); + printf_filtered ("\".\n"); +} +} +{ +struct bound_minimal_symbol bmfun=lookup_minimal_symbol_by_pc(addr); +if (bmfun.minsym) { + printf_filtered ("lookup_minimal_symbol_by_pc \""); + fprintf_symbol_filtered (gdb_stdout, MSYMBOL_PRINT_NAME (bmfun.minsym), + current_language->la_language, DMGL_ANSI); + printf_filtered ("\".\n"); +} +} + + ALL_OBJSECTIONS (objfile, osect) { /* Only process each object file once, even if there's a separate --8t9RHnE3ZwKMSgU+--