From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20310 invoked by alias); 15 May 2014 08:35:29 -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 20297 invoked by uid 89); 15 May 2014 08:35:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f52.google.com Received: from mail-oa0-f52.google.com (HELO mail-oa0-f52.google.com) (209.85.219.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 15 May 2014 08:35:25 +0000 Received: by mail-oa0-f52.google.com with SMTP id eb12so867155oac.11 for ; Thu, 15 May 2014 01:35:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.125.161 with SMTP id mr1mr8587413obb.47.1400142923560; Thu, 15 May 2014 01:35:23 -0700 (PDT) Received: by 10.182.27.105 with HTTP; Thu, 15 May 2014 01:35:23 -0700 (PDT) Date: Thu, 15 May 2014 08:35:00 -0000 Message-ID: Subject: RE: Built-in type handling in gdb From: vijay nag To: "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00022.txt.bz2 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 ?