Invoking methods on gdb.Value objects and other ideas

Invoking methods on gdb.Value objects and other ideas

[Siva Chandra]

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

Re: Invoking methods on gdb.Value objects and other ideas

[Tom Tromey]

>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:

Siva> I am sharing some of my ideas on how we could facilitate invoking
Siva> source language methods (and debug methods) on gdb.Value objects.

Thanks.

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

Sounds good.  We probably should have done it from the start.

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

Likewise.

Siva> 5. Method invocation via [] operator - One should be able to invoke
Siva> methods on a gdb.Value object like this:
Siva>   value_obj[method](arg1, arg2, ...)
Siva> METHOD can be a gdb.TypeMethod, or a gdb.ValueMethod object.

Siva> 6. Unresolved methods - Value and type objects should have Python
Siva> method "get_method".
Siva>   m = value_obj.get_method(method)
Siva> METHOD is a string value name of the method. M is a yet unresolved
Siva> method (due to overloading) but can used to invoke the method like in
Siva> 4 and 5 above. The method is resolved based on the args.

It seems to me that #5 and #6 are just two different ways to write the
same thing.  More or less.

Note that a danger of using strings and overloading [] is that in Java
(and maybe other languages, I don't know) a method and an ordinary field
can have the same name.  I think this would make the syntax ambiguous
there -- is value['name'] a reference to a field or to a bound method?

Perhaps having just get_method is better for this reason.

The above seem to be found methods, but it seems that to be complete
you'd also want a way to create a C++ pointer-to-member.  I guess this
is more cleanly done via the Type API, or perhaps a method on your
proposed TypeMethod object.

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

I wasn't sure about this but I think the idea must be that the internals
cache the result of some other lookup; so that having multiple structs
representing the same type can't cause a problem.  So, it is a
performance optimization rather than an integral part of the lookup
machinery.

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

I don't understand this one.

Tom

Re: Invoking methods on gdb.Value objects and other ideas

[Siva Chandra]

Siva> 5. Method invocation via [] operator - One should be able to invoke
Siva> methods on a gdb.Value object like this:
Siva>   value_obj[method](arg1, arg2, ...)
Siva> METHOD can be a gdb.TypeMethod, or a gdb.ValueMethod object.

Siva> 6. Unresolved methods - Value and type objects should have Python
Siva> method "get_method".
Siva>   m = value_obj.get_method(method)
Siva> METHOD is a string value name of the method. M is a yet unresolved
Siva> method (due to overloading) but can used to invoke the method like in
Siva> 4 and 5 above. The method is resolved based on the args.

Tom> It seems to me that #5 and #6 are just two different ways to write the
Tom> same thing.  More or less.

Yes, more or less :-)
But, note that the method "get_method" takes a string arg, whereas the
operand to '[]' is _not_ a string.  It is a gdb.TypeMethod or
gdb.ValueMethod object.

Tom> Note that a danger of using strings and overloading [] is that in Java
Tom> (and maybe other languages, I don't know) a method and an ordinary field
Tom> can have the same name.  I think this would make the syntax ambiguous
Tom> there -- is value['name'] a reference to a field or to a bound method?

As I mentioned above, we do not use a string operand with '[]' to get methods.

Tom> Perhaps having just get_method is better for this reason.

But, do you think we should not have support for '[]' as described above?

Tom> The above seem to be found methods, but it seems that to be complete
Tom> you'd also want a way to create a C++ pointer-to-member.  I guess this
Tom> is more cleanly done via the Type API, or perhaps a method on your
Tom> proposed TypeMethod object.

I think you mean "bound" methods. I refrained from using that term as
they could be yet unresolved, and they are not gdb.TypeMethod or
gdb.ValueMethod objects. But, I do not have any real reason to not
call them bound methods.

About C++ pointer-to-member values, I think they are in a way methods
already, and hence could just be invoked by '(...)' method invocation?

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

Tom> I wasn't sure about this but I think the idea must be that the internals
Tom> cache the result of some other lookup; so that having multiple structs
Tom> representing the same type can't cause a problem.  So, it is a
Tom> performance optimization rather than an integral part of the lookup
Tom> machinery.

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

Tom> I don't understand this one.

I think you should ignore #7, #8 and #9.  My mistake to have mixed
them up here with the discussion on method invocation.

Re: Invoking methods on gdb.Value objects and other ideas

[Siva Chandra]

Tom> The above seem to be found methods, but it seems that to be complete
Tom> you'd also want a way to create a C++ pointer-to-member.  I guess this
Tom> is more cleanly done via the Type API, or perhaps a method on your
Tom> proposed TypeMethod object.

Siva> About C++ pointer-to-member values, I think they are in a way methods
Siva> already, and hence could just be invoked by '(...)' method invocation?

I think I misread Tom here.

I agree with Tom that a method on gdb.TypeMethod objects could return
a gdb.TypeMethodPtr object.

[With my little experience with GDB, I always use an example to
understand what TYPE_CODE_METHOD and TYPE_CODE_METHODPTR are supposed
to mean and how they differ. Added to this, if type_obj is a gdb.Type
object of type TYPE_CODE_METHOD, type_obj.pointer() does not give a
TYPE_CODE_METHODPTR object!]