This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Function syntax (Was: [RFC][patch 1/9] initial Python support)
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 09 Jun 2008 10:36:21 -0300
- Subject: Re: Function syntax (Was: [RFC][patch 1/9] initial Python support)
- References: <m31w3ketw3.fsf_-_@fleche.redhat.com> <20080608182128.GA6248@caradoc.them.org>
On Sun, 2008-06-08 at 14:21 -0400, Daniel Jacobowitz wrote:
> Except we do need to define what the arguments to specified functions
> are, and I want a clear answer on that point before anything goes in.
> They could be Python syntax, or some other well-defined syntax which
> happens to be similar to Python. Would GDB convenience variables
> work? As values or as textual substitution?
What about separating argument by commas, and treating each CSV as an
expression to be evaluated? The Python function would then receive
arguments as value objects.
This also means that convenience variables (and variables in the
inferior) would work.
The Python function would also return a value object.
> > * I don't want to use $python(...) -- but I was wondering, doesn't
> > this already have a meaning if 'python' happens to be a
> > function-pointer-valued convenience variable?
>
> Yes, but this is always an issue defining new predefined convenience
> variables since they share a namespace with user variables.
I actually prefer the $func(...) syntax. Using $(func args) doesn't feel
natural for non-LISP hackers. The former approach IMHO fits better with
the current GDB syntax, and also with the imperative language used in
the inferior.
--
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center