Re: Built-in type handling in gdb
vijay nag <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAKhyrx-VYpv9Dz4JMC=We2PyM5haL=3FjjnCLhUWnAocxA-E9A@mail.gmail.com> |
On Fri, May 16, 2014 at 10:54 PM, Doug Evans <[email protected]> wrote: > On Thu, May 15, 2014 at 1:35 AM, vijay nag <[email protected]> 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 >> <[email protected]>(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;