This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH 0/7] [python] API for macros


take 2 on the python macro API...
In addition to the testsuite, I tested with the last release of
gcc following: http://gcc.gnu.org/wiki/DebuggingGCC

using variations of the do_stuff function in following script...
I didn't save exact timing #'s but it was something like
 2 mins to count all 600+ million macros
 5 mins to filter all by name with macro.name().startswith()
 15 mins to call the str() method (which calls all other methods).

I'd tried doing a deep copy in the gdb.Macro class,
to avoid all the objfile/obstack/bcache horse pucky evident in this series,
but i killed it before it completed when working with gcc...

it's not really timing equivalent to that last 15 minutes case since
we use lots more memory having a deep copy of all the macros in a symtab in a
list.  Where the 15 minute version does a deep copy, with only one macro's
contents in memory at a time.

thus, I think it is useful even for large projects (if used with care.)
this will fall over if someone has has way too many
macros in a single symtab.  should that happen we can add a macro_map()
that behaves sort of like the python map function.

I think a list is the most straight forward approach for general usage,
and has been shown to work even with projects that use macros extensively.

define read_all_psymtabs
set logging file /tmp/gdb.txt
set logging on
set logging redirect on
maint info psymtabs
# This relies on a side-effect maybe a better way.
shell for i in `grep "text addresses" /tmp/gdb.txt | awk '{print $3}' | sort | uniq`; do echo info line *$i; done >/tmp/foo.gdb
set logging off
python tmp = gdb.execute("source /tmp/foo.gdb", to_string = True);
python tmp = None;
end

python
def do_stuff():
  a_set = set();
  for i in gdb.objfiles():
    if i.is_valid():
      for s in i.symtabs:
        if s.is_valid():
          for a in s.macros():
            name = a.name()
            if name.startswith("TREE"):
              a_set.add(a.is_valid())
  return a_set
end

# hmm, these don't seem to execute if sourced, strange.
read_all_psymtabs
python print do_stuff()

With regards to the hash/compare methods, the implementation of those
is up for debate, I see at least 3 valid ways to compare them and have only one
comparison function.  right now I have it compare deeply e.g. including the whole include_trail
other options that seem valid, compare the name,args,defininition, 
and compare the name,args,definition and partial include_trail
(just definition location) since they pretty much are equal before expansion,
and expansion is an 'expression' thing.

I'd suppose though it's entirely possible for the user to just wrap the object
in another object and DIY comparison method... thats probably the best idea.
I'd defer to an actual user here and let that override `whatever i am using it for
in the testsuite because its convenient.'.  Should we form some kind of opinion i'll
do this in a follow up.

There are some implementation quirks described in the documentation,
some of these are so in the future we can add a gdb.UserMacro which does
a deep-copy on initialization, I wasn't going to add that unless someone
requests it.  Python doesn't seem to have any form of java's `interface',
or abstract base classing at least within our version range,
we could also hack up something ugly in the future to avoid this documentation,
(read union'ify the class implementation,
 or make gdb.Macro have a pointer to a gdb.ObjfileMacro
 and do the lambda macro: macro.method() inside gdb.Macro)
I'd personally just leave it there to give us future choice on the matter.
we can always remove that from the docs if we implement it in a way

matt rice (7):
  [python] API for macros: abort or continuing macro iterators.
  [python] API for macros: memory management quirks.
  [python] API for macros: Add gdb.Macro class.
  [python] API for macros: Add methods to get a gdb.Macro.
  [python] API for macros: gdb.Objfile symtabs method.
  [python] API for macros: Add docs.
  [python] API for macros: Add tests.

 gdb/Makefile.in                       |    6 +
 gdb/NEWS                              |    7 +
 gdb/doc/gdb.texinfo                   |   77 ++++
 gdb/dwarf2read.c                      |    3 +-
 gdb/macrocmd.c                        |    7 +-
 gdb/macroscope.c                      |    2 +-
 gdb/macrotab.c                        |   86 +++--
 gdb/macrotab.h                        |   92 +++--
 gdb/python/py-macro.c                 |  782 +++++++++++++++++++++++++++++++++
 gdb/python/py-macro.h                 |   62 +++
 gdb/python/py-objfile.c               |   42 ++
 gdb/python/py-symtab.c                |  112 +++++
 gdb/python/py-symtab.h                |   26 ++
 gdb/python/python-internal.h          |    1 +
 gdb/python/python.c                   |    1 +
 gdb/symtab.c                          |    3 +-
 gdb/testsuite/gdb.python/py-macro.c   |   87 ++++
 gdb/testsuite/gdb.python/py-macro.exp |  338 ++++++++++++++
 18 files changed, 1665 insertions(+), 69 deletions(-)
 create mode 100644 gdb/python/py-macro.c
 create mode 100644 gdb/python/py-macro.h
 create mode 100644 gdb/python/py-symtab.h
 create mode 100644 gdb/testsuite/gdb.python/py-macro.c
 create mode 100644 gdb/testsuite/gdb.python/py-macro.exp

-- 
1.7.4.4


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]