Re: [RFC] Debug Operators with GDB Python

[Siva Chandra <sivachandra at google dot com>]

Hi Tom,

Thanks for taking a look. Comments inline below.

Siva> What I am looking for is a feedback on the way I am intercepting (in
Siva> value_x_binop and value_x_unop) to perform the operation using the
Siva> Python implementation of the operator.

Tom> It seems reasonable to me.
Tom>
Tom> Have you considered extending this idea to allow Python to supply
Tom> implementations for methods as well?  I see questions periodically about
Tom> optimized-away methods like 'size'.
Tom>
Tom> The reason I ask is that this may affect the choice of where to call to
Tom> Python in the gdb value code.  I'm not sure though.

Similar feedback was given by Doug off-list. I am not sure if you are
hinting at the same thing, but a suggestion was to add the operator
functions to the method table of a class, which can then be
generalized to adding any method to a class. Since we have to cater
for template types, the user will have to provide a type name matcher
rather than specify the type name explicitly. Then, adding a method
would require that we go over all the types in the user's program to
find the right type to add to. Another point is, C++ allows operator
overloading on enum types, in which case we have to add global
functions. Even if we take this route, there could a definition for an
operator (or a method) in the source, which means that we have to
ensure that the selection algorithm in GDB selects the Python
implementation over the source implementation. I think all this can be
done, but IMO it unnecessarily complicates (and probably even clutters
the existing implementation) the implementation of this feature. I
prefer to intercept to invoke Python much before all this kicks in.

I do recognize that having the ability to provide Python
implementations of methods is of great value, but I would prefer to
treat Python operators and Python methods as separate features to
begin with. I would like to implement operators first, and implement
methods (or as Doug suggests, extend it to any function) as the next
step. We might, during the implementation of the methods feature, move
things we added for the operators feature to a common place. Does it
sound like an acceptable plan?

Thanks,
Siva Chandra