This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Built-in type handling in gdb
- From: vijay nag <vijunag at gmail dot com>
- To: Doug Evans <dje at google dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 22 May 2014 10:31:04 +0530
- Subject: Re: Built-in type handling in gdb
- Authentication-results: sourceware.org; auth=none
- References: <CAKhyrx8PRG_OkZtAN=r-1=f9oFm21ZHcC=yO1eyJQXqxZOJFiw at mail dot gmail dot com> <CADPb22Rr7=Nc=NDaTJPgrgZGT-3OpqWuApk_ONnEhGBPuacofA at mail dot gmail dot com> <CAKhyrx-VYpv9Dz4JMC=We2PyM5haL=3FjjnCLhUWnAocxA-E9A at mail dot gmail dot com> <CADPb22TZ3zG+j-4xZt0RDcA+J=kAVSLwzsThQh9CbXSBP0T0xg at mail dot gmail dot com>
On Thu, May 22, 2014 at 1:30 AM, Doug Evans <dje@google.com> 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 <vijunag@gmail.com> wrote:
>> On Fri, May 16, 2014 at 10:54 PM, Doug Evans <dje@google.com> wrote:
>>> On Thu, May 15, 2014 at 1:35 AM, vijay nag <vijunag@gmail.com> 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
>>>> <ken.werner@de.ibm.com>(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 ?