This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Debug Methods in GDB Python


On Fri, Nov 15, 2013 at 4:53 PM, Siva Chandra <sivachandra@google.com> wrote:
> On Fri, Nov 15, 2013 at 4:05 PM, Doug Evans <dje@google.com> 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.
http://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py
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
something simple.
[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[3], 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]