From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30323 invoked by alias); 21 May 2014 20:00:55 -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 30302 invoked by uid 89); 21 May 2014 20:00:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ve0-f179.google.com Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com) (209.85.128.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 21 May 2014 20:00:54 +0000 Received: by mail-ve0-f179.google.com with SMTP id oy12so3162735veb.38 for ; Wed, 21 May 2014 13:00:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZMxB3z1QFgWw1vIA1zHLRarAoMMDrIDpYRhgpJMuqgM=; b=KzkCKeAaKoeelDy5fN+RK2DFDWMhVp6B3o6dntiTYfoJGNQk/tuVhzObCVgOJxCjLn nC9A4V0qBdPVOltDdZmCBjkv5uuT5N7cW4MsDM9GHYTWXj+2IUntxOKw7VaBZF+Eerxi NHHwTT0hnOpUNNqiWPSXa1pYynEtJfSxZbuxsBreITbuXgJEJXqlvivZm9FTbLSerj62 /c4lToc8RRR1PwtZmUzQnIqUKwA2y0HKMsYmHbry8gpRjTDVPQY+1HogN3Adifone3aH VOe3FktgIQmepObxTLwpO/IxzcijT3JSrhMkUtx+mjJDUr8lVyaRLOApf4pMFYK78VOq Cz7Q== X-Gm-Message-State: ALoCoQkpJd6sQkfLWWAZ7VMIZm52XkHDKZNVs0gBymVXmAwxGZgAvTo/oRVgn4r3VFavIMBvAm4Z MIME-Version: 1.0 X-Received: by 10.53.0.135 with SMTP id ay7mr3316365vdd.11.1400702451831; Wed, 21 May 2014 13:00:51 -0700 (PDT) Received: by 10.52.28.230 with HTTP; Wed, 21 May 2014 13:00:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 20:00:00 -0000 Message-ID: Subject: Re: Built-in type handling in gdb From: Doug Evans To: vijay nag Cc: "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00044.txt.bz2 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;