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 Operators with GDB Python


On Fri, Dec 7, 2012 at 11:02 AM, Siva Chandra <sivachandra@google.com> wrote:
> Siva> I would like to implement operators first, and implement
> Siva> methods (or as Doug suggests, extend it to any function) as the next
> Siva> step. We might, during the implementation of the methods feature, move
> Siva> things we added for the operators feature to a common place. Does it
> Siva> sound like an acceptable plan?
>
> Tom> I think it seems weird if you are actually planning to do the next step.
> Tom> Why mess around with something you'll probably end up deprecating in
> Tom> favor of the more general solution?
>
> No. I don't mean to deprecate the first step. What I mean when I say
> "move things" is that we might end up refactoring the implementation
> mechanics of the operators only feature when we implement the
> functions/methods feature. As I have said in another mail, I want to
> treat operators and functions/methods as two separate features. I want
> to do this because I want operators to be available in all languages.
> If we treat operators to be functions/methods, we will probably be
> limiting this feature to C++.

One concern I have is that operators have language-specific behaviour
beyond what the parser knows about.
The current patch intercepts the call before the language-specific
code gets a chance to do its thing.

Two examples besides overloading are inheritance and implicit type conversions.
The pretty-printer support has to handle the former (though there's a
bug there, the details of which I can never remember :-().
And while gdb doesn't yet handle implicit type conversions, it could
some day (I think).
(e.g., if I do "p foo[x]" and x isn't a valid type for [] but it might
have a conversion operator that can be used to make it a valid type)
IWBN if the user didn't have to deal with this, and it all just fell
out from gdb's existing support that it already has to get right if it
hand-called the inferior's operator implementation.
[I realize the current patch handles dynamic types.  It just would be
nice if the existing language support was driving the lookup (though
that can still be done with the current design by having python call
back into gdb to do the lookup).

OTOH, the current patch let's one add operator support to C structs -
dunno if that's useful. :-)  [Though it looks like gdb tries to look
up, e.g. operator[], even for C structs already.]

(gdb) set debug expr 1
(gdb) p b1[42]
Dump of expression @ 0x120e960, before conversion to prefix form:
        Language c, 9 elements, 16 bytes each.
        Index                Opcode         Hex Value  String Value
            0          OP_VAR_VALUE  43  +...............
            1               OP_NULL  0  ................
            2    <unknown 18979408>  18979408  P.!.............
            3          OP_VAR_VALUE  43  +...............
            4               OP_LONG  41  )...............
            5    <unknown 18743280>  18743280  ................
            6             OP_DOUBLE  42  *...............
            7               OP_LONG  41  )...............
            8       BINOP_SUBSCRIPT  23  ................
Dump of expression @ 0x120e960, after conversion to prefix form:
Expression: `b1[42]'
        Language c, 9 elements, 16 bytes each.


            0  BINOP_SUBSCRIPT
            1    OP_VAR_VALUE          Block @0x0, symbol @0x1219a50 (b1)
            5    OP_LONG               Type @0x11dfff0 (int), value 42 (0x2a)
Structure has no component named operator[].
(gdb)


Plus I don't know what behaviours other languages impose on operator support.
The current design may be excessively c++-specific already.
Do you, or anyone, know how this might get used in other languages
that gdb supports?


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