This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: repo to work on python scripting support
On Wed, Mar 26, 2008 at 10:28:53AM -0700, Doug Evans wrote:
> On Mon, Mar 24, 2008 at 10:32 PM, Tom Tromey <tromey@redhat.com> wrote:
> > I've been thinking... maybe we do want $(...) to allow things other
> > than Python commands. Or, more precisely, maybe we want to let Python
> > code register a function by name for use in $(...). The Python
> > function would get the uninterpreted string argument for processing.
>
> OOC, Would there be an intent to not disallow dynamically loaded C/C++
> instead of Python for $(foo)? [Emphasis on OOC.]
My plan on this, to date, has been to insist on use of the Python
interface for marshalling and unmarshalling. This keeps the interface
explicit. Of course, Python can load C modules itself and there'd be
nothing to stop that if you needed to do e.g. some more intensive
computation in the C side; and with a little forethought we could
probably keep likely bulky operations (like memory reading) as
zero-copy.
> Parsing two separate languages in one line is problematic too (I'm not
> sure how far the Pythonic version was intended to be interpreted).
Yes, I think we'll not want to allow raw Python in most GDB
expressions; if it's useful in a convenience expression the
outer layer of quoting should probably belong to GDB.
print $(py "this is a python \"program\"")
--
Daniel Jacobowitz
CodeSourcery