Re: Built-in type handling in gdb

[Doug Evans <dje at google dot com>]

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.