Re: [RFC] Debug Methods in GDB Python

[Doug Evans <dje@google.com>]

On Fri, Nov 15, 2013 at 2:27 PM, Siva Chandra <sivachandra@google.com> wrote:
> Thanks a lot for reviewing.
>
> On Fri, Nov 15, 2013 at 1:59 PM, Tom Tromey <tromey@redhat.com> wrote:
>
>> I can do that if you want; but meanwhile I think if you wrote the
>> tests...
>
> Yes. Now that you are OK with the general approach, I am going to
> write the tests and elaborate the docs. Will send out patches for
> these early next week.
>
>> Also I was curious if this supports operator overloading.  Like can I
>> define an "operator+"?
>
> Yes. Operator overloading is handled the same way as methods. The
> operator functions have to be methods though.
>
>> Siva> +              if (ext_fnp)
>> Siva> +                {
>> Siva> +                  if (ext_fn_is_method (ext_fnp))
>> Siva> +                    {
>> Siva> +                      struct value *ret_val;
>> Siva> +
>> Siva> +                      ret_val = ext_fn_invoke_method (ext_fnp, arg2, argvec + 2,
>> Siva> +                                                      nargs - 1);
>> Siva> +                      if (ret_val == NULL)
>> Siva> +                        error (_("Error invoking debug method for method %s."),
>> Siva> +                               tstr);
>> Siva> +
>> Siva> +                      return ret_val;
>> Siva> +                    }
>> Siva> +                }
>>
>> What happens here if "ext_fnp && !ext_fn_is_method"?
>
>> Siva> +struct py_ext_object
>> Siva> +{
>> Siva> +  /* Holds an instance of the DebugMethod class.  */
>> Siva> +  PyObject *object;
>> Siva> +
>> Siva> +  /* Holds the type of the 'this' object.  */
>> Siva> +  PyObject *match_py_obj_type;
>> Siva> +
>> Siva> +  /* Holds the matching method name.  */
>> Siva> +  const char *match_method;
>>
>> How "match_method" is allocated and how its lifetime is managed is
>> really unclear to me.
>
> I will address the above two question in the next round of review.

Hi.
It's great that you're getting back at this.

I have a few thoughts, nothing burdensome I hope, in random order

It would be good to provide enable/disable/info support akin the the
python pretty-printers.

The original pretty-printers used regexps for matching but that was
IIUC found to be excessively general.
We might want to avoid them in the basic versions of debug methods.

I could be wrong but it seemed like errors were handled differently
than in the pretty-printers.
The inconsistency doesn't feel warranted.

IIRC the "ext_lang" stuff was going to be deleted, right?

I wonder if other users are going to constantly trip on the name
"debug methods" like I do.
I don't have a better name at the moment, but maybe something to think about.

What are debug method groups for?

One thought I had, and this is mostly for discussion's sake,
is why stop at providing support for user-defined methods (incl. operators)?
Why not allow anything that might be "hand called" to be implemented in Python?
[One way of implementing user-defined methods/operators was to
translate, e.g. my_stl_vector[3], into a "pseudo- hand call",
and then call into Python at the point where we would have hand-called
the inferior instead.]

TIA
[and thanks again for getting back to this!]