RE: Built-in type handling in gdb

RE: Built-in type handling in gdb

[vijay nag]

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 ?

Re: Built-in type handling in gdb

[Doug Evans]

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.

Re: Built-in type handling in gdb

[vijay nag]

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;

Re: Built-in type handling in gdb

[Doug Evans]

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;

Re: Built-in type handling in gdb

[vijay nag]

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 ?