Invoking methods on gdb.Value objects and other ideas

Hi all,

I am sharing some of my ideas on how we could facilitate invoking
source language methods (and debug methods) on gdb.Value objects. The
actual API I have in mind, to invoke a method, is very simple and
straightforward. However, I want to propose a re-organization and a
few new features around it to make the Python API cleaner and
intuitive. Most of what I propose in this email might have been
considered earlier and put under a todo list, or rejected as
bad/improper, or rejected in favor of better alternatives. If that is
the case, kindly let me know the reasons for such decisions.

I present my proposal as a sequence of steps. The actual method
invocation API is in the 4th step and could be implemented even if
steps 1-3 are not implemented. Steps 1-3 are, in my opinion, "good to
have" features. Similarly, step 5 and beyond are also "good to have"
features.

1. Bring in a class hierarchy of gdb types. That is, have a base class
gdb.Type from which other classes gdb.TypeStruct, gdb.TypeMethod etc
are derived.

2. Do the same with gdb.Value class. That is, have a base class
gdb.Value from which other classes gdb.ValueStruct, gdb.ValueMethod
etc. are derived. I am not very sure if this is really required, but I
can think of atleast one reason why this can be cleaner.

3. Similar to a suitably named method "fields", gdb.TypeStruct class
should have a method "methods". This will return the list of methods
defined in source language and the debug methods defined in extension
languages. The elements of this list will be gdb.TypeMethod objects.

4. A method is invoked on a gdb.Value object (should be available only
on gdb.ValueStruct and gdb.ValueUnion objects [1] if and when the
value class hierarchy is present) by a Python method "invoke_method".

  value_obj.invoke_method(method, arg1, arg2 ...)

METHOD can be a gdb.TypeMethod object, or a gdb.ValueMethod object, or
a string representing its name.

5. Method invocation via [] operator - One should be able to invoke
methods on a gdb.Value object like this:

  value_obj[method](arg1, arg2, ...)

METHOD can be a gdb.TypeMethod, or a gdb.ValueMethod object.

6. Unresolved methods - Value and type objects should have Python
method "get_method".

  m = value_obj.get_method(method)

METHOD is a string value name of the method. M is a yet unresolved
method (due to overloading) but can used to invoke the method like in
4 and 5 above. The method is resolved based on the args.

7. Installing debug methods on types - gdb.TypeStruct/Union should
have a method "add_method" which installs a debug method into its
underlying "struct type" [2]. This is a kind of debug method grouping
(grouping under a specific type).

8. Debug method caching in the underlying "struct type" [3] - If a
particular debug matches for a type, then cache it in the type. Future
similar invocations need go through all debug methods for a match
(unless of course new debug methods are registered in the meanwhile).

9. Caching debug methods matches to disk - This is for a use case
wherein a GDB user does not write his own debug methods but ends up
implicitly using debug methods defined for a library not written by
him. For such cases, one could cache the debug method matches to disk
so that future GDB sessions save on debug method search.

[1] - Could be other types which represent pointers/references to
struct/union values.
[2] - This is similar to what Doug has proposed for debug methods.
However, debug methods will typically be written for libraries which
can have template classes. The library developer will not in general
have a handle to the template instantiation.
[3] - This is another idea actually mentioned by Doug long time back.

Thanks,
Siva Chandra