From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5999 invoked by alias); 16 May 2014 17:24:36 -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 5986 invoked by uid 89); 16 May 2014 17:24:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f178.google.com Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 16 May 2014 17:24:34 +0000 Received: by mail-vc0-f178.google.com with SMTP id hq16so6720266vcb.9 for ; Fri, 16 May 2014 10:24:32 -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=bogzKFbZPkFJHhKNlK0GLwhSipFvPV90wZyg5fyYyoo=; b=EnwXRSG2PC5z4Pcjm81PniKs4xpqwTpy2f9pmzJ8gwERPYlfkcqazlPXr8FUORsySk xQJwS054BUOyUJBp2eRfJ9s7uHiHEj0eZ3ngZs20iudFeYyPlEX6FfFu8a4DsuqRce7I ao3jxp76Ft3FFnIqyjX+tQTfe1mggsb5vGsjLTCcMxu3G/UsNxQgz0AnMZTXZJwwNagk Z7FNvZyIEeC72rV+Ko+U7E3/YaML81oSMJKW8Ncx8QSvKWkXVW0BEOqVbX82S9ntQ/ml F/Cn24ddVXPwHTz/2AVV1yCtDikj1/hkOxVSrZB5fTx7LIEdxiVs9Omg+dDHYF0zQyWS UZbA== X-Gm-Message-State: ALoCoQlGuPgRJkkVdpvMTmgU4Ja5idwGANnkwUFBqcU//EFU/xeQjJdOEDh5z1u4EL9+RmY6rWm8 MIME-Version: 1.0 X-Received: by 10.220.105.4 with SMTP id r4mr15215804vco.27.1400261072282; Fri, 16 May 2014 10:24:32 -0700 (PDT) Received: by 10.52.68.67 with HTTP; Fri, 16 May 2014 10:24:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 May 2014 17:24: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/msg00027.txt.bz2 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.