public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: tromey@redhat.com, gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [python][patch] Inferior and Thread information support.
Date: Fri, 18 Jun 2010 14:21:00 -0000	[thread overview]
Message-ID: <AANLkTikYKWCnUChWt5DbmBfzaI6lI4bVLROFRe9l3Nz8@mail.gmail.com> (raw)
In-Reply-To: <4C1B16BF.3040000@redhat.com>

Hi.  Just a few comments.

On Thu, Jun 17, 2010 at 11:48 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> +
> +@findex gdb.read_memory
> +@defmethod Inferior read_memory address length
> +Read @var{length} bytes of memory from the inferior, starting at
> +@var{address}.  Returns a buffer object, which behaves much like an array
> +or a string.  It can be modified and given to the @code{gdb.write_memory}
> +function.
> +@end defmethod
> +
> +@findex gdb.write_memory
> +@defmethod Inferior write_memory address buffer @r{[}length@r{]}
> +Write the contents of @var{buffer} to the inferior, starting at
> +@var{address}.  The @var{buffer} parameter must be a Python object
> +which supports the buffer protocol, i.e., a string, an array or the
> +object returned from @code{gdb.read_memory}.  If given, @var{length}
> +determines the number of bytes from @var{buffer} to be written.
> +@end defmethod
> +
> +@findex gdb.search_memory
> +@defmethod Inferior search_memory address length pattern @r{[}size@r{]} @r{[}max_count@r{]}
> +Search a region of the inferior memory starting at @var{address} with the
> +given @var{length}.  @var{pattern} can be a string, a byte array, a buffer
> +object, a number, a @code{gdb.Value} object (@pxref{Values From
> +Inferior}), or a Python list or a tuple with elements in any combination
> +of those types.  If @var{pattern} is a list or a tuple, each element
> +will be extracted and concatenated together to form @var{pattern}.
> +
> +If @var{size} is given and is non-zero, it specifies the size in bytes
> +of a Python scalar or @code{gdb.Value} in the search pattern.  If
> +@var{size} is zero or not specified, the size is taken from the value's type
> +in the current language.  If @var{pattern} is a tuple or list, these
> +actions apply to each element in the tuple or list.  This is useful
> +when one wants to specify the search pattern as a mixture of types.
> +Note that this means, for example, that in the case of C-like
> +languages a search for an untyped 0x42 will search for @samp{(int)
> +0x42} which is typically four bytes.  @var{max_count} is the highest
> +number of matches to search for.
> +@end defmethod
> +@end table

I think search_memory should take just the same type of parameter for
the search pattern that write_memory takes: a byte array (etc.).  Keep
the API simple and let the caller do the conversion to a byte array
(or buffer protocol).
We could provide utilities to convert to/from byte arrays (then
write_memory can use them too!) but Python probably has them already.
Then you can punt on the `size' parameter completely.

You also want to document what the result is.

> +@defivar InferiorThread ptid
> +ID of the thread, as assigned by the operating system.  This attribute is a
> +tuple containing three integers.  The first is the Process ID (PID); the second
> +is the Lightweight Process ID (TID), and the third is the Thread ID (TID).
> +Either the TID or TID may be 0, which indicates that the operating system
> +does not  use that identifier.
> +@end defivar

A couple of typos here: TID is duplicated.

> +# Test max-count with size, with different parameter position
> +
> +gdb_test "py print gdb.inferiors()\[0\].search_memory (start_addr, length, \[0x61, 0x61\], 1, 1)" \
> +  "${one_pattern_found}" "size = 1, max_count = 1"
> +
> +gdb_test "py print gdb.inferiors()\[0\].search_memory (start_addr, length, \[0x61, 0x61\], 1, 2)" \
> +  "${two_patterns_found}" "size = 1, max_count = 2, normal ordering"
> +
> +gdb_test "py print gdb.inferiors()\[0\].search_memory (start_addr, length, \[0x61, 0x61\], size = 1, max_count = 2)" \
> +  "${two_patterns_found}" "size = 1, max_count = 2, normal ordering, with keywords"
> +
> +gdb_test "py print gdb.inferiors()\[0\].search_memory (start_addr, length, \[0x61, 0x61\], max_count = 2, size = 1)" \
> +  "${two_patterns_found}" "size = 1, max_count = 2, inverted ordering"
> +
> +gdb_test "py print gdb.inferiors()\[0\].search_memory (start_addr, length, \['a', 'a'\], max_count = 2)" \
> +  "${two_patterns_found}" "max_count = 2, with keyword"

The CLI testcase for this tests the parameter ordering in order to
test the parsing of the parameters, but you don't need to do that here
(we can trust python on this).  Doesn't hurt though.

  reply	other threads:[~2010-06-18 14:21 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 [this message]
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
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=AANLkTikYKWCnUChWt5DbmBfzaI6lI4bVLROFRe9l3Nz8@mail.gmail.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pmuldoon@redhat.com \
    --cc=tromey@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).