From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3844 invoked by alias); 11 Mar 2014 10:08:50 -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 3833 invoked by uid 89); 11 Mar 2014 10:08:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Mar 2014 10:08:48 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 11 Mar 2014 03:08:47 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga002.fm.intel.com with ESMTP; 11 Mar 2014 03:08:44 -0700 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Mar 2014 10:08:43 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.174]) by IRSMSX151.ger.corp.intel.com ([169.254.4.38]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 10:08:43 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" , "Pedro Alves (palves@redhat.com)" Subject: RE: [PATCH 2/2] btrace: avoid symbol lookup Date: Tue, 11 Mar 2014 10:08:00 -0000 Message-ID: References: <1394182665-14164-1-git-send-email-markus.t.metzger@intel.com> <1394182665-14164-3-git-send-email-markus.t.metzger@intel.com> <20140310214252.GA3105@host2.jankratochvil.net> In-Reply-To: <20140310214252.GA3105@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00260.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] On Behalf Of Jan Kratochvil > Sent: Monday, March 10, 2014 10:43 PM > To: Metzger, Markus T > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH 2/2] btrace: avoid symbol lookup >=20 > 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 sym= bols > > - to avoid surprises when we sometimes get a full symbol and someti= mes > > - only a minimal symbol. */ > > - fun =3D find_pc_function (pc); > > + /* Try to determine the function we're in. */ > > bmfun =3D lookup_minimal_symbol_by_pc (pc); > > mfun =3D 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 =3D NULL; > > + if (mfun =3D=3D NULL) > > + fun =3D find_pc_function (pc); > > + > > if (fun =3D=3D NULL && mfun =3D=3D NULL) > > DEBUG_FTRACE ("no symbol at %s", core_addr_to_string_nz (pc)); > > > [...] >=20 > 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. >=20 > Testcase gdb.dwarf2/dw2-objfile-overlap.exp tests such a case, from: > https://sourceware.org/ml/gdb-patches/2011-11/msg00166.html >=20 > For address of symbol "inner": > * find_pc_function finds DWARF symbol "inner" > * lookup_minimal_symbol_by_pc finds ELF symbol "outer_inner" >=20 > 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. I have not seen DW_AT_ranges used for split functions. OpenMP is a good candidate for this so I checked what gcc 4.8.2 and a recent icc are doing t= oday. Both generate separate functions for parallel regions and describe them as artificial functions in DWARF. Whereas GCC generates a separate local func= tion in ELF, ICC puts the parallel region function after the function it was ext= racted from and describes both as a single function in ELF. For GCC we get a function with a funny name in both cases. For ICC we get a function with a funny name in the DWARF case and the name of the function from which the parallel region has been extracted in the EL= F case. So the result is different in some cases. I'm not sure whether it matters,= though. Inline functions are a different topic. I would like to support them one d= ay. As you point out below, the existing version does not support inline functi= ons either, so some work is necessary. We might need some more work in symbol handling to allow a fast lookup covering only inline functions. We could combine this with the minimal sym= bol lookup to get both inline functions support and reasonable performance. > 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 t= hat > is off-topic here. >=20 > I do not think it will be hit in real world cases. GDB would need some b= etter > abstraction of the symbol kinds to be more systematic in what it outputs. >=20 > It would be good to know how much it helps your usecase as it is not a fu= lly > clean/transparent change. As benchmark, I traced "gdb a.out -ex quit" with a breakpoint on quit_force for debug versions of both gdb and a.out. The tracing GDB was compiled without any additional options; the traced GDB was compiled with "-g -O0". I used a relatively big buffer that contained ~1.5 million instructions. I used "maintenance time 1" to measure the execution time of "info record". The first patch improves performance by ~2x. This patch improves performance by ~3x on top of the first patch. I first tried to cache the returned symbol and check whether the next PC belongs to the same function. My cache hit in ~50% of the cases but showed no benefit. For the majority of the other ~50% no symbol was found. I can= 't cache those. What's missing is a "fast fail", i.e. quickly determine that we won't find = any symbol for this PC. I won't be able to do this in a reasonable amount of t= ime, though, so I thought this patch is a compromise between functionality and performance. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052