This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [rfc] Inferior Functions Calls and Python Values
- From: Tom Tromey <tromey at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Thu, 08 Oct 2009 14:41:20 -0600
- Subject: Re: [rfc] Inferior Functions Calls and Python Values
- References: <4AA765E2.3080808@redhat.com> <4AA9FE37.6060800@redhat.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
Sorry about the delay on this.
Thanks for pinging.
Phil> +Inferior values that represent a function or a function pointer can be
Phil> +called by supplying the arguments to the function in brackets, and
Phil> +calling the value in Python.
This reads strangely to me. For one thing, they aren't brackets, but
parentheses.
How about:
A @code{gdb.Value} that represents a function or a function pointer is a
callable Python object.
Phil> +The arguments provided must match the function prototype of the
Phil> +function or the call will fail. Any errors generated from the
Phil> +inferior function call will be raised as an exception.
I think, "raise as a Python exception", just to be clear.
And, what would an error be?
Does Python API do no argument type-checking at all?
Or does call_function_by_hand do this?
Phil> + vargs[i] = convert_value_from_python (PyTuple_GetItem (args, i));
It seems like you should check the result of PyTuple_GetItem before
calling. convert_value_from_python asserts that the argument is
non-null.
Phil> + /* Check each argument converstion for any exceptions that
Typo, "conversion" .. it appears a few times.
Phil> + if (PyErr_Occurred ())
Phil> + {
Phil> + PyErr_SetString (PyExc_RuntimeError,
Phil> + _("An error was encountered while "
Phil> + "converting an argument for an inferior "
Phil> + "function call. Call aborted."));
Phil> + return NULL;
Phil> + }
You don't need this, just:
if (vargs[i] == NULL)
return NULL;
Phil> + (ternaryfunc)valpy_call, /*tp_call*/
Space after close paren.
Phil> +#include <signal.h>
[...]
Phil> + raise (SIGABRT);
I'm not sure this is ok.
Do any other gdb tests do this?
What happens if you make an inferior function call and the inferior hits
a breakpoint during the call?
Tom