public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [python][patch] Inferior and Thread information support.
Date: Fri, 25 Jun 2010 20:38:00 -0000	[thread overview]
Message-ID: <m3r5ju4zlt.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4C209107.9010800@redhat.com> (Phil Muldoon's message of "Tue, 22	Jun 2010 11:31:35 +0100")

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> I've done this.  Threads do not have the same registry mechanism yet, so
Phil> I've had to keep the old observer mechanism there.  But inferiors use
Phil> the new registry cleanup.

Phil> I've also simplified the search_memory api as requested.  We now take
Phil> an address, a length and a buffer only.  We now only return the first
Phil> match found in the buffer. (and let the user do the iteration in the
Phil> scripting side).

Phil> Latest patch attached. WDYT?

Phil> +PyObject *
Phil> +inferior_to_inferior_object (struct inferior *inferior)
Phil> +{
Phil> +  inferior_object *inf_obj;
Phil> +
Phil> +  inf_obj = inferior_data (inferior, infpy_inf_data_key);
Phil> +  if (!inf_obj)
Phil> +    {
Phil> +      struct cleanup *cleanup;
Phil> +      cleanup = ensure_python_env (python_gdbarch, python_language);
Phil> +
Phil> +      inf_obj = PyObject_New (inferior_object, &inferior_object_type);
[...]
Phil> +      do_cleanups (cleanup);
Phil> +    }
Phil> +  else
Phil> +    Py_INCREF (inf_obj);
Phil> +
Phil> +  return (PyObject *) inf_obj;

Right now the reference counting is inconsistent here.  Either a new
reference should be returned, and the Py_INCREF always done; or it
should return a borrowed reference, and this Py_INCREF removed.  I
prefer the borrowed reference approach.  I try to document this sort of
thing in the function's header comment.

Phil> +  cleanup = ensure_python_env (python_gdbarch, python_language);
Phil> +
Phil> +  thread_obj = create_thread_object (tp);
Phil> +  if (!thread_obj)
Phil> +    {
Phil> +      warning (_("Cannot create Python InferiorThread object."));
Phil> +      gdbpy_print_stack ();
Phil> +      do_cleanups (cleanup);

I don't think there is any need for a warning here.
The exception should suffice.

Phil> +static PyObject *
Phil> +infpy_get_was_attached (PyObject *self, void *closure)
Phil> +{
Phil> +  inferior_object *inf = (inferior_object *) self;
Phil> +  INFPY_REQUIRE_VALID (inf);

You need a blank line between these two lines now.

Phil> +static int
Phil> +build_inferior_list (struct inferior *inf, void *arg)
Phil> +{
Phil> +  PyObject *list = arg;
Phil> +  PyObject *inferior = inferior_to_inferior_object (inf);
Phil> +  PyList_Append (list, inferior);

Likewise.

Phil> +/* Implementation of gdb.read_memory (address, length).
Phil> +   Returns a Python buffer object with LENGTH bytes of the inferior's
Phil> +   memory at ADDRESS.  Both arguments are integers.  */
Phil> +static PyObject *
Phil> +infpy_read_memory (PyObject *self, PyObject *args)
Phil> +{
Phil> +  int error = 0;
Phil> +  CORE_ADDR addr, length;
Phil> +  void *buffer = NULL;
Phil> +  membuf_object *membuf_obj;
Phil> +  PyObject *addr_obj, *length_obj;
Phil> +  struct cleanup *cleanups;
Phil> +  volatile struct gdb_exception except;
Phil> +
Phil> +  if (! PyArg_ParseTuple (args, "OO", &addr_obj, &length_obj))
Phil> +    return NULL;

I hate to add on, but I think all functions taking 2 or more arguments
should accept keyword arguments.

Phil> +  cleanups = make_cleanup (null_cleanup, NULL);
Phil> +
Phil> +  TRY_CATCH (except, RETURN_MASK_ALL)
Phil> +    {
Phil> +      if (!get_addr_from_python (addr_obj, &addr)
Phil> +	  || !get_addr_from_python (length_obj, &length))
Phil> +	{
Phil> +	  error = 1;
Phil> +	  break;
Phil> +	}
Phil> +
Phil> +      buffer = xmalloc (length);
Phil> +      make_cleanup (xfree, buffer);
Phil> +
Phil> +      read_memory (addr, buffer, length);
Phil> +    }
Phil> +  GDB_PY_HANDLE_EXCEPTION (except);

GDB_PY_HANDLE_EXCEPTION returns from the function; this will leave the
cleanups dangling.  You have to run the cleanups before the return.

Phil> +static PyObject *
Phil> +infpy_write_memory (PyObject *self, PyObject *args)
Phil> +{
Phil> +  int buf_len, error = 0;
Phil> +  const char *buffer;
Phil> +  CORE_ADDR addr, length;
Phil> +  PyObject *addr_obj, *length_obj = NULL;
Phil> +  volatile struct gdb_exception except;
Phil> +
Phil> +  if (! PyArg_ParseTuple (args, "Os#|O", &addr_obj, &buffer, &buf_len,
Phil> +			  &length_obj))
Phil> +    return NULL;

Likewise about the keyword arguments.

Phil> +/* Implementation of InferiorThread.newest_frame () -> gdb.Frame.
Phil> +   Returns the newest frame object.  */
Phil> +PyObject *
Phil> +thpy_newest_frame (PyObject *self, PyObject *args)

This function should be static...

But, do we want it at all?  If the frame comes from some other thread,
there is almost no useful operation we can do with it.

That said I think the code for the function is fine.  If we have some
use case then I'm ok with it.

Tom

  reply	other threads:[~2010-06-25 20:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-24 13:36 Phil Muldoon
2010-05-24 18:06 ` Eli Zaretskii
2010-06-10 18:40 ` Tom Tromey
2010-06-14 12:42   ` Phil Muldoon
2010-06-15 15:24     ` Pedro Alves
2010-06-15 18:11     ` Tom Tromey
2010-06-15 18:24       ` Pedro Alves
2010-06-15 19:58       ` Phil Muldoon
2010-06-15 20:36         ` Pedro Alves
2010-06-18  6:49   ` Phil Muldoon
2010-06-18 14:21     ` Doug Evans
2010-06-18 15:47       ` Phil Muldoon
2010-06-18 17:59         ` Tom Tromey
2010-06-18 20:10           ` Phil Muldoon
2010-06-25 20:41             ` Tom Tromey
2010-06-18 18:04     ` Tom Tromey
2010-06-22 10:32       ` Phil Muldoon
2010-06-25 20:38         ` Tom Tromey [this message]
2010-06-28  9:22           ` Phil Muldoon
2010-06-28 19:51             ` Tom Tromey
2010-06-28 21:35               ` Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3r5ju4zlt.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pmuldoon@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).