Re: [RFC] Debug Operators with GDB Python

[Siva Chandra <sivachandra at google dot com>]

Let me try this time by trying to break up what we are discussing into
two topics. I am probably repeating some of what I have already said.

Topic 1: Should debug operators be allowed in languages other than
C++? If yes, my opinion is that we should not treat them as methods or
functions that can be added/replaced via a GDB Python API. A user
should be able to add them without thinking them to be
methods/functions. Consequently, what I am saying is that we should
treat Python debug operators (API 1) and Python debug
methods/functions (API 2) to be two separate features provided with
two separate APIs. In C++, let us allow the user to add operators by
using either one of these APIs. Though we ended up calling these as
steps, I think what I have been meaning is to first implement API 1
treating it to be independent of API 2. When we implement API 2, we
might end up moving/modifying the underlying mechanics of API 1, but
not change API 1 itself.

Topic 2: This topic is about where exactly should we be intercepting
the current GDB flow to enable the above two APIs. Putting the problem
of this topic in another way, how of much of existing GDB
infrastructure should/can we use. My opinion here is biased by the
opinion I have for topic 1 above. To be frank, though I have ideas, I
have not given much thought to API 2 yet. For API 1, my comments are
inline below.

On Tue, Dec 4, 2012 at 1:37 PM, Doug Evans <dje@google.com> wrote:
> There may be a disconnect, so let me take a step back.
> One question is, besides overloading, how much more of the c++
> language itself comes into play here?

For API 1 at least, overloading is not a problem. Hence, my claim is
that we can bypass all that infrastructure which does overload
resolution.

I can think of two others:
1. Is a relationship: If class A is a base class of class B, then an
operator defined on A should also be applicable for B. This is
probably applicable for any language which supports inheritance. For
API 1, this can be handled completely in Python.
2. Dynamic types: I have initially thought that we should handle
dynamic types correctly, but I am now of the opinion that the user
implementing the operator should handle this. And, this might call for
another capability: ability to invoke source methods on gdb.Value
objects.

> I could be missing something, but for the task at hand do we need to
> know, in advance, what class to add the methods to?  I can envision
> implementations that don't.

I have concerns only if it is required to do an 'add'. If you are OK
with a design which does not add, then I do not have any concerns.

> Hmm, that reminds me of another thing.  The parameter matchers need to
> support regular-expression based matching, but I think we need to
> leave it to the operator author to decide how to actually perform the
> match.  We would provide utilities to make the common case simple, but
> we can't hardwire in the inability to handle more complex cases.

I plan to make this part of the API similar to that of the pretty printing API.