This is the mail archive of the
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: Tue, 19 Nov 2013 15:41:58 -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> <CADPb22TgkC-KBhAoYvNBueOKrHAFWwvd9TgYaQ2=Oq5qsFoZrA at mail dot gmail dot com> <CAGyQ6gwtj3TEazHJYvVNwbZnN3hh6ZJD_dcG4spZ56hkXaP2ag at mail dot gmail dot com>
On Fri, Nov 15, 2013 at 4:53 PM, Siva Chandra <email@example.com> wrote:
> On Fri, Nov 15, 2013 at 4:05 PM, Doug Evans <firstname.lastname@example.org> wrote:
>> It would be good to provide enable/disable/info support akin the the
>> python pretty-printers.
> Yes. I am planning to bring them in the next version of the patches.
>> 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.
> Do you have an alternate approach in mind?
For matching the class I would look into how the current version of
the libstdc++ pretty-printers do this.
I don't know if that's the best way to handle debug methods, but doing
something different requires a compelling reason.
For matching on the method, I would just use a string comparison.
Again, this is for the simple version. IIUC the API allows for more
complex mechanisms, but for the start I'd say start small with
[I can imagine an issue arising with operators, e.g., "operator ()" vs
"operator()" or some such. Is handling that with a regexp the best
way to go? Dunno.]
>> I could be wrong but it seemed like errors were handled differently
>> than in the pretty-printers.
>> The inconsistency doesn't feel warranted.
> Yes, there is a difference.
>> IIRC the "ext_lang" stuff was going to be deleted, right?
> I am not sure. Tom had a comment long time back on this, but his
> latest review said that his comments on this might be irrelevant now.
> I have renamed some of the pieces related to this in my last patch. Do
> you have any specific comments?
The name is a tad confusing, though I'm warming up to it.
The high order bit for me is you're really just abstracting away a
subset of a much bigger problem space: The abstraction of all calls
from gdb-proper to the extension language.
>> What are debug method groups for?
> They are for disabling and enabling a group of debug methods. For
> example, they could be used for debugging the debug methods themselves
> or writing tests for them: You can disable a group at once instead of
> disabling individually.
Ah. The python pretty-printers support this differently.
Again, I think there needs to be a compelling reason to do it differently.
For example, note how grouping is handled there.
IWBN if the user commands for enable/disable/info were as consistent
as possible between the two.
>> 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?
> I think that could be a fairly straightforward extension. Do you want
> it to be done together with this work?
Naw, I don't want to delay this work by adding more features.
OTOH, I do think there is value to at least thinking about the future
and not making extending what's there now harder than it otherwise
could have been (to the extent that one can reasonably reason about
such things without delaying the implementation forever).
>> [One way of implementing user-defined methods/operators was to
>> translate, e.g. my_stl_vector, into a "pseudo- hand call",
>> and then call into Python at the point where we would have hand-called
>> the inferior instead.]
> IIRC, you had suggested similar ideas earlier as well. However, I have
> not gone that route because I thought debug methods/functions should
> go through the method/function matching infrastructure. Am I missing
> something here?
My thought was that they *would* go through the method/function
matching infrastructure, and out of that would be an appropriately
crafted "hand call". It's not critical though.
One thing I noticed in the patch is an assumption of an initial "this" pointer.
While it doesn't have to be implemented today, I think we should at
least know *how* it will be handled in the API, and that is, e.g.,
static methods where there is no "this".
APIs are harder to change than implementations.