Re: [RFC] Debug Operators with GDB Python

[Doug Evans <dje at google dot com>]

On Sun, Dec 2, 2012 at 7:25 AM, Siva Chandra <sivachandra@google.com> wrote:
> 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?

I would like to not go down the operator-only path without clear knowledge that:
- if we want to rewrite it later we can do so (e.g. gdb does a bit of
computation to select the right operator/method to invoke.
Intercepting as early as this patch does means we bypass that and
would have to somehow deal with it in Python - a later
reimplementation would then mean throwing all that away, and it's not
clear to me it could be done so in a way that doesn't risk breaking
someone's existing Python code)
- a design that includes methods is excessively hard

Regarding templates,
pretty-printers for, e.g., stl vectors, already have to handle this issue.
To me it's a solvable problem (not involving excessive effort).

On a slightly related note,
one of the problems of the current pretty-printer implementation is
that we do a linear search through all printers looking for a match
every time we go to print something.
One way to improve on this is to cache the printer found with its type
(I think - haven't actually tried it).
I can imagine doing a similar thing with operator/method support if
the initial implementation proved too slow.
[It's not the only solution.]