Re: Built-in type handling in gdb

[Doug Evans <dje at google dot com>]

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;