This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Debug Operators with GDB Python
- From: Tom Tromey <tromey at redhat dot com>
- To: Siva Chandra <sivachandra at google dot com>
- Cc: gdb-patches at sourceware dot org, Doug Evans <dje at google dot com>
- Date: Fri, 07 Dec 2012 11:00:27 -0700
- Subject: Re: [RFC] Debug Operators with GDB Python
- References: <CAGyQ6gx6pYxK91gvsL2zSa18Wk5eJPJw4wr0fU6AdH+TLuiPpw@mail.gmail.com> <email@example.com> <CAGyQ6gwuBofeT1emdGXqAXBPVGZPKycGrySaRpo6w=upSd7YAw@mail.gmail.com>
>>>>> "Siva" == Siva Chandra <firstname.lastname@example.org> writes:
Siva> Since we have to cater for template types, the user will have to
Siva> provide a type name matcher rather than specify the type name
Siva> explicitly. Then, adding a method would require that we go over
Siva> all the types in the user's program to find the right type to add
Ok, I see.
It still seems a shame since I think this is functionality we're going
to want someday anyway. "print vec.size()" is a frequent user problem,
we ought to solve it somehow.
But given the design (cough cough) of the symbol table and other
factors, it does seem difficult.
I suppose in a way there are two different problems here. One is
substituting a gdb-side Python function for some request to an inferior
function call. This one seems relatively doable in full generality.
The other problem is adding new global functions or methods. This seems
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?
I think it seems weird if you are actually planning to do the next step.
Why mess around with something you'll probably end up deprecating in
favor of the more general solution?