From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22217 invoked by alias); 22 May 2014 05:01:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22202 invoked by uid 89); 22 May 2014 05:01:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-oa0-f41.google.com Received: from mail-oa0-f41.google.com (HELO mail-oa0-f41.google.com) (209.85.219.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 22 May 2014 05:01:06 +0000 Received: by mail-oa0-f41.google.com with SMTP id m1so3404691oag.0 for ; Wed, 21 May 2014 22:01:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.74.67 with SMTP id r3mr54276908oev.9.1400734864700; Wed, 21 May 2014 22:01:04 -0700 (PDT) Received: by 10.182.27.105 with HTTP; Wed, 21 May 2014 22:01:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 05:01:00 -0000 Message-ID: Subject: Re: Built-in type handling in gdb From: vijay nag To: Doug Evans Cc: "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00046.txt.bz2 On Thu, May 22, 2014 at 1:30 AM, Doug Evans wrote: > Hi. > As a quick hack, sure. > It's not something that can get checked into the gdb repository, but > I've used that exact hack myself. :-) > > On Mon, May 19, 2014 at 3:59 AM, vijay nag wrote: >> On Fri, May 16, 2014 at 10:54 PM, Doug Evans wrote: >>> On Thu, May 15, 2014 at 1:35 AM, vijay nag wrote: >>>> Hello GDB, >>>> >>>> I have a simple GDB script to walk through the heap given a core file. >>>> The data types used in the scripts are all primitive C data types and >>>> any non primitive user defined data types have been avoided to speed >>>> up the execution. In the older version of GDB(say gdb-7.0) this script >>>> finished execution in a jiffy, the new gdb is way too slow in >>>> execution. I built gdb-7.0/7.6 from source and observed the difference >>>> in execution. >>>> >>>> As part of this commit "NEWS: Mention OpenCL C language support >>>> 2010-11-05 Ken Werner >>>> (https://github.com/dov/gdb/commit/100d4cd4f6f42014c07e6acd0d9b6187d1259b2e) >>>> * c-exp.y: Lookup the primitive types instead of referring to the >>>> builtins.", parse_type macro(get from builtin) has been changed to a >>>> function call lookup_signed_typename(). This function seems to be >>>> doing an exhaustive global/static symbols search even for a C >>>> primitive data type(say int) there by consuming plenty of CPU cycles. >>>> Should we be doing this exhaustive search of data types from the >>>> binary file even for basic C primitive data types ? >>> >>> Hi. >>> >>> I agree the current situation is less then stellar. >>> >>> There is one catch that needs to be handled that isn't necessarily obvious. >>> The size of each primitive type is specific to each .o file (CU in >>> DWARF parlance). >>> E.g., If I compile foo.c with -fshort-double then sizeof(double) == 4 in foo.o. >>> While it's difficult for an app to make this work in general, gdb >>> should still support it. >>> >>> The order in which types should be looked up is: >>> - current CU >>> - builtin type >>> - globally (fallback in the case of base types) >>> [N.B. that's a qualified "globally" as base types live in gdb's STATIC_BLOCK] >>> >>> I think the fix isn't that hard, but it will require some changes to >>> symbol lookup of base types. >>> It's on my TODO list, but I'm happy to guide anyone through the >>> changes required. >> >> Hello Doug, >> >> Is the below patch plausible ? I have basically changed the look-up >> order of user defined data type and primitive data type. >> >> diff --git a/systemsw/tools/src/gdb-7.6/gdb/gdbtypes.c >> b/systemsw/tools/src/gdb-7.6/gdb/gdbtypes.c >> index 12730d7..8211b35 100644 >> --- a/systemsw/tools/src/gdb-7.6/gdb/gdbtypes.c >> +++ b/systemsw/tools/src/gdb-7.6/gdb/gdbtypes.c >> @@ -1201,13 +1201,14 @@ lookup_typename (const struct language_defn *language, >> struct symbol *sym; >> struct type *type; >> >> + type = language_lookup_primitive_type_by_name (language, gdbarch, name); >> + if (type) >> + return type; >> + >> sym = lookup_symbol (name, block, VAR_DOMAIN, 0); >> if (sym != NULL && SYMBOL_CLASS (sym) == LOC_TYPEDEF) >> return SYMBOL_TYPE (sym); >> >> - type = language_lookup_primitive_type_by_name (language, gdbarch, name); >> - if (type) >> - return type; >> >> if (noerr) >> return NULL; What is the plausible fix for this ? Can you please guide me ?