Re: RFC: new command to search memory

["Doug Evans" <dje@google.com>]

On Jan 28, 2008 11:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > +@table @code
> > +
> > +@kindex find
> > +@item find @r{[}/@var{size}@r{]} @r{[}/@var{max_count}@r{]} @var{start_addr}, @@@var{len}, @var{val1} @r{[}, @var{val2}, ...@r{]}
> > +@itemx find @r{[}/@var{size}@r{]} @r{[}/@var{max_count}@r{]} @var{start_addr}, @var{end_addr}, @var{val1} @r{[}, @var{val2}, ...@r{]}
>
> These two lines are two long, and since they are in @code, TeX will
> not wrap them, and they will overflow the page margins in print.  So
> please make them shorter somehow.  Here's one idea:
>
>   @item find @r{[}/@var{options} @var{where} @dots{}
>
> and then describe ``options'' and ``where'' separately.
>
> Also, please use @dots{} instead of literal "...", the former looks
> better in print.
>
> > +@var{size} specifies how to interpret the search pattern and is
> > +'b' for 8-bit values, 'h' for 16-bit values, 'w' for 32-bit values,
>
> Please use @samp{b}, @samp{h} etc.


Righto.


> +Strings may be specified for search values, quote them normally.
>
> Is this language-dependent?  If not, then ``normally'' doesn't really
> cut it; please describe specifically how to quote.


The string is not language dependent.  I guess it could be, but I'm
not sure there's sufficient value here.  Consider the printf command.
One thing that might be useful is to merge the respective string
parsing in each command (assuming they take equivalent strings).


> > +The string value is copied into the search pattern byte by byte,
> > +regardless of the endianness of the target and the size specification.
>
> This begs the question: what about non-printable characters? are they
> supported, and if so, how?


The string parser uses parse_escape so they can be embedded in the
string.  One can also do it this way:

find /b mumble, "search string ", 1, 127, 253, " with embedded
non-printable characters"
find mumble, "search string ", (char) 1, (char) 127, (char) 253, "with
embedded non-printable characters"

I can update the docs on what the string may contain.


> > +The address of the last value found is stored in convenience variable
> > +@samp{$numfound}.
> > +A count of the number of matches is stored in @samp{$_}.
>
> Your example has this the other way around (and so does the code,
> IIUC):


Oops, thanks for catching that.


> > +@item qSearch:memory:@var{address};@var{length};@var{search-pattern}
> > +@cindex search memory
>
> You already have "@cindex searching memory" where you describe `find',
> so this almost identical index entry in a totally different place
> would be confusing: the reader will not know which entry is relevant
> for them.  I suggest this instead:
>
>   @cindex searching memory, in remote debugging
>
> > +@cindex @samp{qSearch:memory} packet
> > +@anchor{qSearch memory}
> > +Search LENGTH bytes at ADDRESS for SEARCH-PATTERN.
> > +ADDRESS and LENGTH are encoded in hex.
> > +SEARCH-PATTERN is a sequence of bytes, hex encoded.
> > +
> > +Reply:
> > +@table @samp
> > +@item 0
> > +The pattern was not found.
> > +@item 1,address
> > +The pattern was found at ADDRESS.
>
> This should use @var{length}, @var{address}, instead of LENGTH,
> ADDRESS, etc.: in lower-case and in @var.

Righto.