This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Debug Methods in GDB Python
- From: Doug Evans <dje at google dot com>
- To: Siva Chandra <sivachandra at google dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 15 Nov 2013 16:05:42 -0800
- Subject: Re: [RFC] Debug Methods in GDB Python
- Authentication-results: sourceware.org; auth=none
- References: <CAGyQ6gyKTCdcjMcbfnc4zV3+yEt9tCTJzS8eW92dQrQzikRaTQ at mail dot gmail dot com> <CAGyQ6gxzG8vuPyFKHpacHS7W7jMEReidWDBkNJjywOXADXgVnw at mail dot gmail dot com> <87r4hefx59 dot fsf at fleche dot redhat dot com> <CAGyQ6gw_-MOu4Y9D+mUf-A55_Ms+j9JAmM9dU0y8PdJw73EkNw at mail dot gmail dot com> <871u995pbt dot fsf at fleche dot redhat dot com> <CAGyQ6gywGMDwmm9fHpPGhwE9vrki1VE8uDM2hRFEAvCZKaTyJg at mail dot gmail dot com> <87ehaq5nkr dot fsf at fleche dot redhat dot com> <CAGyQ6gwT5+Jmu4bqgakjCWmmZtWjbd83n0qq=B9ctfWjv7oS_w at mail dot gmail dot com> <87txfds4vf dot fsf at fleche dot redhat dot com> <CAGyQ6gzaht0KYTxdFFZDeAo5hxesOmjCAiVomX8d_eV4XGK_CQ at mail dot gmail dot 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!]