This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python API problems
- From: Rich Lane <rlane at club dot cc dot cmu dot edu>
- To: Joseph Garvin <joseph dot h dot garvin at gmail dot com>
- Cc: gdb <gdb at sourceware dot org>
- Date: Wed, 27 Jan 2010 15:29:26 -0500
- Subject: Re: Python API problems
- References: <fea8ac9f1001271127w7efe3c38gfcb2a49eca6eb854@mail.gmail.com>
Excerpts from Joseph Garvin's message of 2010-01-27 14:27:05 -0500:
> -That could be worked around if gdb.execute returned a string
> containing what information would otherwise have gone to the console.
> Then we could at least parse the output. This would be nice in general
> for working around API holes until they're filled. Because of this I
> can't even manually search the output from "info functions" (though
> searching that would be slooooooow).
I worked around this with a terrible hack:
def gdbx(cmd):
fd, filename = tempfile.mkstemp('.gdb-out')
gdb.execute("set logging off")
gdb.execute("set logging file" + filename)
gdb.execute("set logging redirect on")
gdb.execute("set logging on")
try:
gdb.execute(cmd)
finally:
gdb.execute("set logging off")
gdb.execute("set logging redirect off")
str = os.fdopen(fd).read()
os.remove(filename)
return str.strip()
Unfortunately, this doesn't work if you try to use "interpreter-exec mi"
to get easily parseable output.
There's an open bug: http://sourceware.org/bugzilla/show_bug.cgi?id=10808
I'm also very much looking forward to the python API becoming more
complete. It would be useful to have the function parameters in a Frame
object, for example.