This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: repo to work on python scripting support
>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
Jim> On Tue, Mar 25, 2008 at 11:18:12AM -0700, Jim Blandy wrote:
Jim> I don't know the most Pythonish way of doing things, but it seems to
Jim> me that Python could register not functions, but objects, to be
Jim> callable with $().
Daniel> Hmm, I've worked with some packages that did similar things using
Daniel> mandatory docstrings.
We could use decorators.
http://wiki.python.org/moin/PythonDecorators
Well, assuming they exist. I'm not really that up on the current
state of Python.
For this particular thing I would be just as happy with some explicit
constructor thing:
class Strcmp(GdbFunction):
def __init__(self):
Strcmp.__init__(self, 'strcmp', 'ee')
def invoke(expr1, expr2):
lalala
You could also use a real data structure and named constants:
Strcmp.__init__(self, 'strcmp', (gdb.EXPRESSION, gdb.EXPRESSION))
.. or what have you.
Aside from the interactive spec, the current gdb-python support for
command objects already works this way. A command subclass has to
pass in the user-visible command name at construction time.
FWIW here's the code I wrote to override "edit" and turn it into an
annotation-based command:
class Edit(gdb.Command):
def __init__(self):
gdb.Command.__init__(self, "edit", gdb.COMMAND_NONE)
def invoke(self, arg, fromtty):
if gdb.show('annotate') > -1:
loc = gdb.decode_line(arg)
if loc:
loc = loc[0]
if loc.symtab.to_fullname():
print "\n\x1a\x1asource %s:%d:0:beg:0x0" \
% (loc.symtab.to_fullname(), loc.get_line())
# Install it.
Edit()
Just to be clear, I don't really want to consider anything in this
area as fixed. Advice and input about how everything should fit
together is really helpful.
Tom