[RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Hi,

This is a follow up to this thread:
https://sourceware.org/ml/gdb/2013-11/msg00101.html

Part of Doug's response there seemed to indicate that calling
overloaded operators to perform valid Python operations has not yet
been implemented. The attached patch adds this "feature". I could not
yet think of a reason as to why adding this could be bad (as in,
leading to ambiguity or something similar).

ChangeLog

2013-12-02  Siva Chandra Reddy  <sivachandra@google.com>

        Call overloaded operators to perform valid Python operations on
        struct/class values.

        * python/py-value.c (valpy_binop): Call value_x_binop for struct
        and class values.

        testsuite/
        * gdb.python/py-value-cc.cc: Improve test case.
        * gdb.python/py-value-cc.exp: Add new tests.

[-- Attachment #2: python_op_patch_v1.txt --]
[-- Type: text/plain, Size: 6393 bytes --]

diff --git a/gdb/python/py-value.c b/gdb/python/py-value.c
index 40254b9..22c2dbc 100644
--- a/gdb/python/py-value.c
+++ b/gdb/python/py-value.c
@@ -762,6 +762,8 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
       struct value *arg1, *arg2;
       struct cleanup *cleanup = make_cleanup_value_free_to_mark (value_mark ());
       struct value *res_val = NULL;
+      enum exp_opcode op = OP_NULL;
+      int handled = 0;
 
       /* If the gdb.Value object is the second operand, then it will be passed
 	 to us as the OTHER argument, and SELF will be an entirely different
@@ -793,6 +795,7 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 	    CHECK_TYPEDEF (rtype);
 	    rtype = STRIP_REFERENCE (rtype);
 
+            handled = 1;
 	    if (TYPE_CODE (ltype) == TYPE_CODE_PTR
 		&& is_integral_type (rtype))
 	      res_val = value_ptradd (arg1, value_as_long (arg2));
@@ -800,7 +803,10 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 		     && is_integral_type (ltype))
 	      res_val = value_ptradd (arg2, value_as_long (arg1));
 	    else
-	      res_val = value_binop (arg1, arg2, BINOP_ADD);
+              {
+                handled = 0;
+                op = BINOP_ADD;
+              }
 	  }
 	  break;
 	case VALPY_SUB:
@@ -813,6 +819,7 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 	    CHECK_TYPEDEF (rtype);
 	    rtype = STRIP_REFERENCE (rtype);
 
+            handled = 1;
 	    if (TYPE_CODE (ltype) == TYPE_CODE_PTR
 		&& TYPE_CODE (rtype) == TYPE_CODE_PTR)
 	      /* A ptrdiff_t for the target would be preferable here.  */
@@ -822,38 +829,49 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 		     && is_integral_type (rtype))
 	      res_val = value_ptradd (arg1, - value_as_long (arg2));
 	    else
-	      res_val = value_binop (arg1, arg2, BINOP_SUB);
+              {
+	         handled = 0;
+                 op = BINOP_SUB;
+              }
 	  }
 	  break;
 	case VALPY_MUL:
-	  res_val = value_binop (arg1, arg2, BINOP_MUL);
+	  op = BINOP_MUL;
 	  break;
 	case VALPY_DIV:
-	  res_val = value_binop (arg1, arg2, BINOP_DIV);
+	  op = BINOP_DIV;
 	  break;
 	case VALPY_REM:
-	  res_val = value_binop (arg1, arg2, BINOP_REM);
+	  op = BINOP_REM;
 	  break;
 	case VALPY_POW:
-	  res_val = value_binop (arg1, arg2, BINOP_EXP);
+	  op = BINOP_EXP;
 	  break;
 	case VALPY_LSH:
-	  res_val = value_binop (arg1, arg2, BINOP_LSH);
+	  op = BINOP_LSH;
 	  break;
 	case VALPY_RSH:
-	  res_val = value_binop (arg1, arg2, BINOP_RSH);
+	  op = BINOP_RSH;
 	  break;
 	case VALPY_BITAND:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_AND);
+	  op = BINOP_BITWISE_AND;
 	  break;
 	case VALPY_BITOR:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_IOR);
+	  op = BINOP_BITWISE_IOR;
 	  break;
 	case VALPY_BITXOR:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_XOR);
+	  op = BINOP_BITWISE_XOR;
 	  break;
 	}
 
+      if (!handled)
+        {
+          if (binop_user_defined_p (op, arg1, arg2))
+            res_val = value_x_binop (arg1, arg2, op, OP_NULL, EVAL_NORMAL);
+          else
+            res_val = value_binop (arg1, arg2, op);
+        }
+
       if (res_val)
 	result = value_to_value_object (res_val);
 
diff --git a/gdb/testsuite/gdb.python/py-value-cc.cc b/gdb/testsuite/gdb.python/py-value-cc.cc
index c010fc9..ff605c4 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.cc
+++ b/gdb/testsuite/gdb.python/py-value-cc.cc
@@ -16,8 +16,19 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 class A {
+ public:
+  int operator+ (const int a);
+
+ public:
+  int a_;
 };
 
+int
+A::operator+ (const int a)
+{
+  return a + a_;
+}
+
 typedef int *int_ptr;
 
 int
@@ -35,5 +46,8 @@ int
 main ()
 {
   A obj;
+
+  obj.a_ = 5;
+
   return func (obj);
 }
diff --git a/gdb/testsuite/gdb.python/py-value-cc.exp b/gdb/testsuite/gdb.python/py-value-cc.exp
index 55c3b97..026deb5 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.exp
+++ b/gdb/testsuite/gdb.python/py-value-cc.exp
@@ -34,13 +34,30 @@ if ![runto_main] {
 gdb_breakpoint [gdb_get_line_number "Break here."]
 gdb_continue_to_breakpoint "Break here" ".*Break here.*"
 
-gdb_test "python print (str(gdb.parse_and_eval(\"a\").type))" "const A &"
-gdb_test "python print (str(gdb.parse_and_eval(\"a\").referenced_value().type))" "const A"
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ref\").type))" "int &"
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ref\").referenced_value().type))" "int"
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ref\").referenced_value()))" "10"
-
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ptr_ref\").dereference().type))" "int"
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ptr_ref\").referenced_value().type))" "int_ptr"
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ptr_ref\").referenced_value().dereference()))" "10"
-gdb_test "python print (str(gdb.parse_and_eval(\"int_ptr_ref\").referenced_value().referenced_value()))" "10"
+gdb_test_no_output "python a = gdb.parse_and_eval('a')" "eval a"
+gdb_test_no_output "python int_ref = gdb.parse_and_eval('int_ref')" \
+  "eval int_ref"
+gdb_test_no_output "python int_ptr_ref = gdb.parse_and_eval('int_ptr_ref')" \
+  "eval int_ptr_ref"
+
+# Tests for gdb.Value.referenced_value()
+gdb_test "python print str(a.type)" "const A &" "a.type"
+gdb_test "python print str(a.referenced_value().type)" "const A" \
+  "a.referenced_value().type"
+gdb_test "python print str(int_ref.type)" "int &" "int_ref.type"
+gdb_test "python print str(int_ref.referenced_value().type)" "int" \
+  "int_ref.referenced_value().type"
+gdb_test "python print str(int_ref.referenced_value())" "10" \
+  "int_ref.referenced_value()"
+
+gdb_test "python print str(int_ptr_ref.dereference().type)" "int" \
+  "int_ptr_ref.dereference().type"
+gdb_test "python print str(int_ptr_ref.referenced_value().type)" "int_ptr" \
+  "int_ptr_ref.referenced_value().type"
+gdb_test "python print str(int_ptr_ref.referenced_value().dereference())" \
+  "10" "int_ptr_ref.referenced_value().dereference()"
+gdb_test "python print str(int_ptr_ref.referenced_value().referenced_value())" \
+  "10" "int_ptr_ref.referenced_value().referenced_value()"
+
+# Test overloaded operators.
+gdb_test "python print a + 5" "10" "a + 5"

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Doug Evans]

Siva Chandra <sivachandra@google.com> writes:
> Hi,
>
> This is a follow up to this thread:
> https://sourceware.org/ml/gdb/2013-11/msg00101.html
>
> Part of Doug's response there seemed to indicate that calling
> overloaded operators to perform valid Python operations has not yet
> been implemented. The attached patch adds this "feature". I could not
> yet think of a reason as to why adding this could be bad (as in,
> leading to ambiguity or something similar).
>
> ChangeLog
>
> 2013-12-02  Siva Chandra Reddy  <sivachandra@google.com>
>
>         Call overloaded operators to perform valid Python operations on
>         struct/class values.
>
>         * python/py-value.c (valpy_binop): Call value_x_binop for struct
>         and class values.
>
>         testsuite/
>         * gdb.python/py-value-cc.cc: Improve test case.
>         * gdb.python/py-value-cc.exp: Add new tests.

Hi.

I'm not yet comfortable enough with going this route to approve it.
It feels sexy and all, but it's not clear to me going this path is a net win.
If we could release it as experimental, without any promises to keep it
or change it in incompatible ways, I'd say go for it.
I'm curious what others think.

Nits on the patch itself:

1) In the changelog entry, no blank line here.

>         Call overloaded operators to perform valid Python operations on
>         struct/class values.
>  <<<no blank line here>>>
>         * python/py-value.c (valpy_binop): Call value_x_binop for struct
>         and class values.

2) NEWS entry and doc required.
I can well imagine that they're coming, pending approval of the patch
thus far.  Sorry!

3) gdb code uses tabs for indentation (and then uses spaces after the
needed amount of tabs have been used), and it's a pain when tabbed
code is mixed with non-tabbed code.

4) In the test case, don't make extra changes, or if you do split
them out into a separate patch.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

Thanks for taking a look Doug. I will address the nits if there is
interest in getting this in.

On Thu, Dec 5, 2013 at 10:24 PM, Doug Evans <xdje42@gmail.com> wrote:
> It feels sexy and all, but it's not clear to me going this path is a net win.
> If we could release it as experimental, without any promises to keep it
> or change it in incompatible ways, I'd say go for it.
> I'm curious what others think.

My main motivation to have something like this has been to aid
implementing "debug methods" that I have in my other patch. Same can
be said about non-operator methods as well, but clearly, allowing
methods to be invoked via the '.' operator on gdb.Value objects is
bad. I could not think of any reason why it could be bad to not allow
operators.

Thanks,
Siva Chandra
PS: For methods in general, I have ideas on how we can facilitate
calling them from Python. But, it is probably premature at this point
to talk about it if we have not yet decided about how "debug methods"
feature would eventually look like.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Tom Tromey]

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> I'm not yet comfortable enough with going this route to approve it.

It seems fine to me.

Doug> It feels sexy and all, but it's not clear to me going this path is
Doug> a net win.

What are the negatives?  Your email leaves little to either agree or
argue with.  A little more insight into your reasoning might be useful.

Tom

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Tom Tromey]

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

Siva> PS: For methods in general, I have ideas on how we can facilitate
Siva> calling them from Python. But, it is probably premature at this point
Siva> to talk about it if we have not yet decided about how "debug methods"
Siva> feature would eventually look like.

It seems like an orthogonal topic to me.
I'd appreciate hearing your ideas.

Tom

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Doug Evans]

On Wed, Dec 11, 2013 at 12:17 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
>
> Doug> I'm not yet comfortable enough with going this route to approve it.
>
> It seems fine to me.
>
> Doug> It feels sexy and all, but it's not clear to me going this path is
> Doug> a net win.
>
> What are the negatives?  Your email leaves little to either agree or
> argue with.  A little more insight into your reasoning might be useful.

My concern is basically that one can only go so far mapping Python to
the target language (or, can we get a "mode" (for lack of a better
word) in Python of accepting the syntax of the target language?)

Does it make sense to support what one can (arithmetic ops, a few
others), and leave it at that?  I don't know.
Every feature adds complexity, and this feature can never be complete
(I could certainly be wrong ... it would be interesting if all C++
operators could be supported).

Note that I'm not disapproving the feature ... if someone else
approves the patch I'm not going to object.
For myself, I'm just going slow on this one.  E.g., is there another
way to provide this?
E.g., some kind of facility that uses gdb's language parsers but let's
one pass in gdb.Value objects from Python?
It sounds doable, but I haven't thought about it very hard (it might
not even make sense, or it may require more effort).
Its drawback to the current proposal is that it would be a bit more
verbose, but it has to potential of handling a lot more cases.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

On Sun, Dec 15, 2013 at 11:48 PM, Doug Evans <xdje42@gmail.com> wrote:
> For myself, I'm just going slow on this one.  E.g., is there another
> way to provide this?
> E.g., some kind of facility that uses gdb's language parsers but let's
> one pass in gdb.Value objects from Python?
> It sounds doable, but I haven't thought about it very hard (it might
> not even make sense, or it may require more effort).
> Its drawback to the current proposal is that it would be a bit more
> verbose, but it has to potential of handling a lot more cases.

I am not sure I fully understand this alternative.  My patch adds the
ability to use valid Python operators on gdb.Value objects in Python
code.  Operators which have different semantics in Python (like '[]',
',' etc.), and operators which do not exist in Python (like '->')
cannot be facilitated.  But, my patch adds the ability to use all
other operators which are valid (as far as my understanding today
stands at) in Python.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Doug Evans]

On Mon, Dec 16, 2013 at 2:24 PM, Siva Chandra <sivachandra@google.com> wrote:
> On Sun, Dec 15, 2013 at 11:48 PM, Doug Evans <xdje42@gmail.com> wrote:
>> For myself, I'm just going slow on this one.  E.g., is there another
>> way to provide this?
>> E.g., some kind of facility that uses gdb's language parsers but let's
>> one pass in gdb.Value objects from Python?
>> It sounds doable, but I haven't thought about it very hard (it might
>> not even make sense, or it may require more effort).
>> Its drawback to the current proposal is that it would be a bit more
>> verbose, but it has to potential of handling a lot more cases.
>
> I am not sure I fully understand this alternative.

It could be done in various ways I think.  One way would be language parsers
and the evaluator have some way of recognizing a value as coming from
an extension language and fetch the underlying gdb value accordingly.
Kinda like the gdb.parse_and_eval method in Python, but with the
ability to pass Python values to it.

Not that this could work, but for illustration's sake:
smart_ptr = gdb.parse_and_eval ("my_smart_ptr");
dereferenced_smart_ptr = gdb.parse_and_eval("*%V" % smart_ptr)

I can think of a quick hack that was just a wrapper on parse_and_eval that
used some convenience variables to temporarily hold the values that
came from Python (using some syntax that worked, the above
is just for illustration's sake).

> My patch adds the
> ability to use valid Python operators on gdb.Value objects in Python
> code.  Operators which have different semantics in Python (like '[]',
> ',' etc.), and operators which do not exist in Python (like '->')
> cannot be facilitated.  But, my patch adds the ability to use all
> other operators which are valid (as far as my understanding today
> stands at) in Python.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

On Wed, Dec 18, 2013 at 8:37 AM, Doug Evans <xdje42@gmail.com> wrote:
> Not that this could work, but for illustration's sake:
> smart_ptr = gdb.parse_and_eval ("my_smart_ptr");
> dereferenced_smart_ptr = gdb.parse_and_eval("*%V" % smart_ptr)

Should work. May be the '%' syntax would not (I am not sure). But, we
could consider other alternatives [Replace occurrences of $1, $2, etc
for example].

Is this an exhaustive solution or a cool fallback option when no other
Pythonic way works? Consider something more complicated but uses only
valid Python operators:

  C++:
    obj1.method1(obj2_ptr->method2(obj3 + obj4)) * obj5

  This could be done in a Pythonic way as:
    obj1.invoke('method1', obj2_ptr.invoke('method2', obj3 + obj4)) * obj5

  If we do this in a string replacement way:
    gdb.parse_and_eval('$1.method1($2->method2($3 + $4)) * $5',
                        obj1, obj2_ptr, obj3, obj4, obj5)

Above, the values objN in Python are equivalents of their C++ values.
Also, I have cooked up the 'invoke' method on gdb.Value objects but we
could have one for real. Lets see how your example would look like
with this 'invoke' in place:

  C++:
    *my_smart_ptr;

  Python:
    smart_ptr.invoke('operator*')

Or, one could have a debug method named "deref" (assuming debug
methods would soon be a reality :-) to be an equivalent of
"operator*". The Python would then look like this:
    smart_ptr.invoke('deref')

[Side topic: Should smart_ptr.dereference() invoke 'operator*'? The
documentation says this: "... behavior of Value.dereference is
identical to applying the C unary operator * on a given value." And, I
remember writing this myself :-)]

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Doug Evans]

On Wed, Dec 18, 2013 at 3:15 PM, Siva Chandra <sivachandra@google.com> wrote:
> On Wed, Dec 18, 2013 at 8:37 AM, Doug Evans <xdje42@gmail.com> wrote:
>> Not that this could work, but for illustration's sake:
>> smart_ptr = gdb.parse_and_eval ("my_smart_ptr");
>> dereferenced_smart_ptr = gdb.parse_and_eval("*%V" % smart_ptr)
>
> Should work. May be the '%' syntax would not (I am not sure). But, we
> could consider other alternatives [Replace occurrences of $1, $2, etc
> for example].
>
> Is this an exhaustive solution or a cool fallback option when no other
> Pythonic way works

Both?
[Not sure I understand the question.]

> [Side topic: Should smart_ptr.dereference() invoke 'operator*'? The
> documentation says this: "... behavior of Value.dereference is
> identical to applying the C unary operator * on a given value." And, I
> remember writing this myself :-)]

Dunno.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

dje> smart_ptr = gdb.parse_and_eval ("my_smart_ptr");
dje> dereferenced_smart_ptr = gdb.parse_and_eval("*%V" % smart_ptr)

siva> Should work. May be the '%' syntax would not (I am not sure). But, we
siva> could consider other alternatives [Replace occurrences of $1, $2, etc
siva> for example].

siva> Is this an exhaustive solution or a cool fallback option when no other
siva> Pythonic way works

dje> Both?
dje> [Not sure I understand the question.]

I do think it is exhaustive. But, somehow [only a subjective feeling],
seems like a fallback option. For example, it makes simple things
(like, val1 + val2) more verbose and less readable. It is something
which one could fallback to if they want to do non-Python operations.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

I do not think there was an agreement on whether to have this feature
or not. Based on the points raised by Doug, my personal opinion is
that we should have this feature along with the facility (which in my
opinion is a cool fallback when no other Pythonic way works) suggested
by Doug.  To keep the discussion moving for both the ideas, I am
sending a patch which addresses the nits pointed out by Doug on my
first patch.  I will hopefully find time during the holidays to work
on the feature suggested by Doug.

2013-12-20  Siva Chandra Reddy  <sivachandra@google.com>

        Call overloaded operators to perform valid Python operations on
        struct/class values.
        * NEWS (Python Scripting): Add entry for this new feature.
        * python/py-value.c (valpy_binop): Call value_x_binop for struct
        and class values.

        testsuite/
        * gdb.python/py-value-cc.cc: Improve test case to enable testing
        operations on gdb.Value objects.
        * gdb.python/py-value-cc.exp: Add new test to test operations on
        gdb.Value objects.

        doc/
        * gdb.texinfo (Values From Inferior): Add description about
        performing valid Python operations on gdb.Value objects.

[-- Attachment #2: python_op_patch_v2.txt --]
[-- Type: text/plain, Size: 5953 bytes --]

diff --git a/gdb/NEWS b/gdb/NEWS
index e4baf50..b712fdd 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -42,6 +42,9 @@
   ** Line tables representation has been added.
   ** New attribute 'parent_type' for gdb.Field objects.
   ** gdb.Field objects can be used as subscripts on gdb.Value objects.
+  ** Valid Python operations on gdb.Value objects representing
+     structs/classes invokes the corresponding overloaded operators if
+     available.
 
 * New targets
 
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index b7551c2..0ca0880 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -23974,7 +23974,23 @@ bar = some_val + 2
 
 @noindent
 As result of this, @code{bar} will also be a @code{gdb.Value} object
-whose values are of the same type as those of @code{some_val}.
+whose values are of the same type as those of @code{some_val}.  Valid
+Python operations can also be performed on @code{gdb.Value} objects
+representing @code{struct}s/@code{class}es.  For such cases, the
+overloaded operator (if present), is used to perform the operation.
+For example, if @code{val1}and @code{val2} are @code{gdb.Value} objects
+representing instances of a @code{class} which has an overloaded
+operator defined for the @code{+} operator, then one can use the
+@code{+} operator in their Python script as follows:
+
+@smallexample
+val3 = val1 + val2
+@end smallexample
+
+@noindent
+The result of the operation @code{val3} is also a @code{gdb.Value}
+object corresponding to the value returned by the overloaded @code{+}
+operator.
 
 Inferior values that are structures or instances of some class can
 be accessed using the Python @dfn{dictionary syntax}.  For example, if
diff --git a/gdb/python/py-value.c b/gdb/python/py-value.c
index df25179..6c2458c 100644
--- a/gdb/python/py-value.c
+++ b/gdb/python/py-value.c
@@ -884,6 +884,8 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
       struct value *arg1, *arg2;
       struct cleanup *cleanup = make_cleanup_value_free_to_mark (value_mark ());
       struct value *res_val = NULL;
+      enum exp_opcode op = OP_NULL;
+      int handled = 0;
 
       /* If the gdb.Value object is the second operand, then it will be passed
 	 to us as the OTHER argument, and SELF will be an entirely different
@@ -915,6 +917,7 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 	    CHECK_TYPEDEF (rtype);
 	    rtype = STRIP_REFERENCE (rtype);
 
+	    handled = 1;
 	    if (TYPE_CODE (ltype) == TYPE_CODE_PTR
 		&& is_integral_type (rtype))
 	      res_val = value_ptradd (arg1, value_as_long (arg2));
@@ -922,7 +925,10 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 		     && is_integral_type (ltype))
 	      res_val = value_ptradd (arg2, value_as_long (arg1));
 	    else
-	      res_val = value_binop (arg1, arg2, BINOP_ADD);
+	      {
+		handled = 0;
+		op = BINOP_ADD;
+	      }
 	  }
 	  break;
 	case VALPY_SUB:
@@ -935,6 +941,7 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 	    CHECK_TYPEDEF (rtype);
 	    rtype = STRIP_REFERENCE (rtype);
 
+	    handled = 1;
 	    if (TYPE_CODE (ltype) == TYPE_CODE_PTR
 		&& TYPE_CODE (rtype) == TYPE_CODE_PTR)
 	      /* A ptrdiff_t for the target would be preferable here.  */
@@ -944,38 +951,49 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 		     && is_integral_type (rtype))
 	      res_val = value_ptradd (arg1, - value_as_long (arg2));
 	    else
-	      res_val = value_binop (arg1, arg2, BINOP_SUB);
+	      {
+		handled = 0;
+		op = BINOP_SUB;
+	      }
 	  }
 	  break;
 	case VALPY_MUL:
-	  res_val = value_binop (arg1, arg2, BINOP_MUL);
+	  op = BINOP_MUL;
 	  break;
 	case VALPY_DIV:
-	  res_val = value_binop (arg1, arg2, BINOP_DIV);
+	  op = BINOP_DIV;
 	  break;
 	case VALPY_REM:
-	  res_val = value_binop (arg1, arg2, BINOP_REM);
+	  op = BINOP_REM;
 	  break;
 	case VALPY_POW:
-	  res_val = value_binop (arg1, arg2, BINOP_EXP);
+	  op = BINOP_EXP;
 	  break;
 	case VALPY_LSH:
-	  res_val = value_binop (arg1, arg2, BINOP_LSH);
+	  op = BINOP_LSH;
 	  break;
 	case VALPY_RSH:
-	  res_val = value_binop (arg1, arg2, BINOP_RSH);
+	  op = BINOP_RSH;
 	  break;
 	case VALPY_BITAND:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_AND);
+	  op = BINOP_BITWISE_AND;
 	  break;
 	case VALPY_BITOR:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_IOR);
+	  op = BINOP_BITWISE_IOR;
 	  break;
 	case VALPY_BITXOR:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_XOR);
+	  op = BINOP_BITWISE_XOR;
 	  break;
 	}
 
+      if (!handled)
+	{
+	  if (binop_user_defined_p (op, arg1, arg2))
+	    res_val = value_x_binop (arg1, arg2, op, OP_NULL, EVAL_NORMAL);
+	  else
+	    res_val = value_binop (arg1, arg2, op);
+	}
+
       if (res_val)
 	result = value_to_value_object (res_val);
 
diff --git a/gdb/testsuite/gdb.python/py-value-cc.cc b/gdb/testsuite/gdb.python/py-value-cc.cc
index 80094ec..60c2182 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.cc
+++ b/gdb/testsuite/gdb.python/py-value-cc.cc
@@ -17,9 +17,18 @@
 
 class A {
  public:
+  int operator+ (const int a1);
+
+ public:
   int a;
 };
 
+int
+A::operator+ (const int a1)
+{
+  return a + a1;
+}
+
 union U {
   int a;
   char c;
@@ -65,5 +74,7 @@ main ()
 {
   A obj;
 
+  obj.a = 5;
+
   return func (obj);
 }
diff --git a/gdb/testsuite/gdb.python/py-value-cc.exp b/gdb/testsuite/gdb.python/py-value-cc.exp
index eacaf2e..fb1176d 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.exp
+++ b/gdb/testsuite/gdb.python/py-value-cc.exp
@@ -79,3 +79,7 @@ gdb_test "python print(b_td\[b_fields\[0\]\]\['a'\])" "100" \
 
 gdb_test "python print(u\[u_fields\[0\]\])" "99.*" "u's first field via field"
 gdb_test "python print(u\[u_fields\[1\]\])" "99.*" "u's second field via field"
+
+# Test overloaded operators.
+gdb_test_no_output "python a = gdb.parse_and_eval('a')" "init a"
+gdb_test "python print a + 5" "10" "a + 5"

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Eli Zaretskii]

> Date: Fri, 20 Dec 2013 14:29:36 -0800
> From: Siva Chandra <sivachandra@google.com>
> Cc: Tom Tromey <tromey@redhat.com>, Doug Evans <dje@google.com>
> 
> I do not think there was an agreement on whether to have this feature
> or not. Based on the points raised by Doug, my personal opinion is
> that we should have this feature along with the facility (which in my
> opinion is a cool fallback when no other Pythonic way works) suggested
> by Doug.  To keep the discussion moving for both the ideas, I am
> sending a patch which addresses the nits pointed out by Doug on my
> first patch.  I will hopefully find time during the holidays to work
> on the feature suggested by Doug.

Thanks.

> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -42,6 +42,9 @@
>    ** Line tables representation has been added.
>    ** New attribute 'parent_type' for gdb.Field objects.
>    ** gdb.Field objects can be used as subscripts on gdb.Value objects.
> +  ** Valid Python operations on gdb.Value objects representing
> +     structs/classes invokes the corresponding overloaded operators if
> +     available.      ^^^^^^^

"invoke", in plural.

> +Python operations can also be performed on @code{gdb.Value} objects
> +representing @code{struct}s/@code{class}es.  For such cases, the

These tricks don't look good in print, due to changes in typefaces.
Suggest to rephrase

  representing a @code{struct} or a @code{class}.

> +                                         which has an overloaded
> +operator defined for the @code{+} operator

"which overloads the @code{+} operator" sounds better, and is surely
shorter and more concise.

The documentation parts are OK with those changes.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

As I said in my previous post on this thread, I do not think there was
a yes or a no decision made about this feature. Hence, I am continuing
to respond to comments. Attached is the latest version which addresses
Eli'c comments.

2013-12-30  Siva Chandra Reddy  <sivachandra@google.com>

        Call overloaded operators to perform valid Python operations on
        struct/class values.
        * NEWS (Python Scripting): Add entry for this new feature.
        * python/py-value.c (valpy_binop): Call value_x_binop for struct
        and class values.

        testsuite/
        * gdb.python/py-value-cc.cc: Improve test case to enable testing
        operations on gdb.Value objects.
        * gdb.python/py-value-cc.exp: Add new test to test operations on
        gdb.Value objects.

        doc/
        * gdb.texinfo (Values From Inferior): Add description about
        performing valid Python operations on gdb.Value objects.

[-- Attachment #2: python_op_patch_v3.txt --]
[-- Type: text/plain, Size: 5932 bytes --]

diff --git a/gdb/NEWS b/gdb/NEWS
index b64967e..11fb5dd 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -44,6 +44,9 @@
   ** Line tables representation has been added.
   ** New attribute 'parent_type' for gdb.Field objects.
   ** gdb.Field objects can be used as subscripts on gdb.Value objects.
+  ** Valid Python operations on gdb.Value objects representing
+     structs/classes invoke the corresponding overloaded operators if
+     available.
 
 * New targets
 
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a60e6cf..1a4a1de 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -23961,7 +23961,23 @@ bar = some_val + 2
 
 @noindent
 As result of this, @code{bar} will also be a @code{gdb.Value} object
-whose values are of the same type as those of @code{some_val}.
+whose values are of the same type as those of @code{some_val}.  Valid
+Python operations can also be performed on @code{gdb.Value} objects
+representing a @code{struct} or @code{class} object.  For such cases,
+the overloaded operator (if present), is used to perform the operation.
+For example, if @code{val1}and @code{val2} are @code{gdb.Value} objects
+representing instances of a @code{class} which overloads the @code{+}
+operator, then one can use the @code{+} operator in their Python script
+as follows:
+
+@smallexample
+val3 = val1 + val2
+@end smallexample
+
+@noindent
+The result of the operation @code{val3} is also a @code{gdb.Value}
+object corresponding to the value returned by the overloaded @code{+}
+operator.
 
 Inferior values that are structures or instances of some class can
 be accessed using the Python @dfn{dictionary syntax}.  For example, if
diff --git a/gdb/python/py-value.c b/gdb/python/py-value.c
index df25179..6c2458c 100644
--- a/gdb/python/py-value.c
+++ b/gdb/python/py-value.c
@@ -884,6 +884,8 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
       struct value *arg1, *arg2;
       struct cleanup *cleanup = make_cleanup_value_free_to_mark (value_mark ());
       struct value *res_val = NULL;
+      enum exp_opcode op = OP_NULL;
+      int handled = 0;
 
       /* If the gdb.Value object is the second operand, then it will be passed
 	 to us as the OTHER argument, and SELF will be an entirely different
@@ -915,6 +917,7 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 	    CHECK_TYPEDEF (rtype);
 	    rtype = STRIP_REFERENCE (rtype);
 
+	    handled = 1;
 	    if (TYPE_CODE (ltype) == TYPE_CODE_PTR
 		&& is_integral_type (rtype))
 	      res_val = value_ptradd (arg1, value_as_long (arg2));
@@ -922,7 +925,10 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 		     && is_integral_type (ltype))
 	      res_val = value_ptradd (arg2, value_as_long (arg1));
 	    else
-	      res_val = value_binop (arg1, arg2, BINOP_ADD);
+	      {
+		handled = 0;
+		op = BINOP_ADD;
+	      }
 	  }
 	  break;
 	case VALPY_SUB:
@@ -935,6 +941,7 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 	    CHECK_TYPEDEF (rtype);
 	    rtype = STRIP_REFERENCE (rtype);
 
+	    handled = 1;
 	    if (TYPE_CODE (ltype) == TYPE_CODE_PTR
 		&& TYPE_CODE (rtype) == TYPE_CODE_PTR)
 	      /* A ptrdiff_t for the target would be preferable here.  */
@@ -944,38 +951,49 @@ valpy_binop (enum valpy_opcode opcode, PyObject *self, PyObject *other)
 		     && is_integral_type (rtype))
 	      res_val = value_ptradd (arg1, - value_as_long (arg2));
 	    else
-	      res_val = value_binop (arg1, arg2, BINOP_SUB);
+	      {
+		handled = 0;
+		op = BINOP_SUB;
+	      }
 	  }
 	  break;
 	case VALPY_MUL:
-	  res_val = value_binop (arg1, arg2, BINOP_MUL);
+	  op = BINOP_MUL;
 	  break;
 	case VALPY_DIV:
-	  res_val = value_binop (arg1, arg2, BINOP_DIV);
+	  op = BINOP_DIV;
 	  break;
 	case VALPY_REM:
-	  res_val = value_binop (arg1, arg2, BINOP_REM);
+	  op = BINOP_REM;
 	  break;
 	case VALPY_POW:
-	  res_val = value_binop (arg1, arg2, BINOP_EXP);
+	  op = BINOP_EXP;
 	  break;
 	case VALPY_LSH:
-	  res_val = value_binop (arg1, arg2, BINOP_LSH);
+	  op = BINOP_LSH;
 	  break;
 	case VALPY_RSH:
-	  res_val = value_binop (arg1, arg2, BINOP_RSH);
+	  op = BINOP_RSH;
 	  break;
 	case VALPY_BITAND:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_AND);
+	  op = BINOP_BITWISE_AND;
 	  break;
 	case VALPY_BITOR:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_IOR);
+	  op = BINOP_BITWISE_IOR;
 	  break;
 	case VALPY_BITXOR:
-	  res_val = value_binop (arg1, arg2, BINOP_BITWISE_XOR);
+	  op = BINOP_BITWISE_XOR;
 	  break;
 	}
 
+      if (!handled)
+	{
+	  if (binop_user_defined_p (op, arg1, arg2))
+	    res_val = value_x_binop (arg1, arg2, op, OP_NULL, EVAL_NORMAL);
+	  else
+	    res_val = value_binop (arg1, arg2, op);
+	}
+
       if (res_val)
 	result = value_to_value_object (res_val);
 
diff --git a/gdb/testsuite/gdb.python/py-value-cc.cc b/gdb/testsuite/gdb.python/py-value-cc.cc
index 80094ec..60c2182 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.cc
+++ b/gdb/testsuite/gdb.python/py-value-cc.cc
@@ -17,9 +17,18 @@
 
 class A {
  public:
+  int operator+ (const int a1);
+
+ public:
   int a;
 };
 
+int
+A::operator+ (const int a1)
+{
+  return a + a1;
+}
+
 union U {
   int a;
   char c;
@@ -65,5 +74,7 @@ main ()
 {
   A obj;
 
+  obj.a = 5;
+
   return func (obj);
 }
diff --git a/gdb/testsuite/gdb.python/py-value-cc.exp b/gdb/testsuite/gdb.python/py-value-cc.exp
index eacaf2e..fb1176d 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.exp
+++ b/gdb/testsuite/gdb.python/py-value-cc.exp
@@ -79,3 +79,7 @@ gdb_test "python print(b_td\[b_fields\[0\]\]\['a'\])" "100" \
 
 gdb_test "python print(u\[u_fields\[0\]\])" "99.*" "u's first field via field"
 gdb_test "python print(u\[u_fields\[1\]\])" "99.*" "u's second field via field"
+
+# Test overloaded operators.
+gdb_test_no_output "python a = gdb.parse_and_eval('a')" "init a"
+gdb_test "python print a + 5" "10" "a + 5"

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Eli Zaretskii]

> Date: Mon, 30 Dec 2013 06:40:40 -0800
> From: Siva Chandra <sivachandra@google.com>
> Cc: gdb-patches <gdb-patches@sourceware.org>, Tom Tromey <tromey@redhat.com>, 	Doug Evans <dje@google.com>
> 
> As I said in my previous post on this thread, I do not think there was
> a yes or a no decision made about this feature. Hence, I am continuing
> to respond to comments. Attached is the latest version which addresses
> Eli'c comments.

OK for the documentation parts.

Thanks.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Siva Chandra]

ping.

Any decision on this patch/feature?

> 2013-12-30  Siva Chandra Reddy  <sivachandra@google.com>
>
>         Call overloaded operators to perform valid Python operations on
>         struct/class values.
>         * NEWS (Python Scripting): Add entry for this new feature.
>         * python/py-value.c (valpy_binop): Call value_x_binop for struct
>         and class values.
>
>         testsuite/
>         * gdb.python/py-value-cc.cc: Improve test case to enable testing
>         operations on gdb.Value objects.
>         * gdb.python/py-value-cc.exp: Add new test to test operations on
>         gdb.Value objects.
>
>         doc/
>         * gdb.texinfo (Values From Inferior): Add description about
>         performing valid Python operations on gdb.Value objects.

Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values.

[Doug Evans]

On Wed, Jan 22, 2014 at 1:39 PM, Siva Chandra <sivachandra@google.com> wrote:
> ping.
>
> Any decision on this patch/feature?
>
>> 2013-12-30  Siva Chandra Reddy  <sivachandra@google.com>
>>
>>         Call overloaded operators to perform valid Python operations on
>>         struct/class values.
>>         * NEWS (Python Scripting): Add entry for this new feature.
>>         * python/py-value.c (valpy_binop): Call value_x_binop for struct
>>         and class values.
>>
>>         testsuite/
>>         * gdb.python/py-value-cc.cc: Improve test case to enable testing
>>         operations on gdb.Value objects.
>>         * gdb.python/py-value-cc.exp: Add new test to test operations on
>>         gdb.Value objects.
>>
>>         doc/
>>         * gdb.texinfo (Values From Inferior): Add description about
>>         performing valid Python operations on gdb.Value objects.

Hi.  Thanks for persevering.

Tom said it seems fine to him, and I've expressed my thoughts.

Seems like a green light to me.

IWBN if the docs listed exactly which operations are supported.
Ok with that change.
[I realize this patch relies on the user-defined method patch, so it
can't go in just yet.]

Thanks again for persevering.