From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8575 invoked by alias); 30 Jan 2008 18:06:28 -0000 Received: (qmail 8558 invoked by uid 22791); 30 Jan 2008 18:06:26 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jan 2008 18:06:09 +0000 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id m0UI63KD029705 for ; Wed, 30 Jan 2008 10:06:03 -0800 Received: from wa-out-1112.google.com (wahk34.prod.google.com [10.114.237.34]) by zps77.corp.google.com with ESMTP id m0UI59VO005219 for ; Wed, 30 Jan 2008 10:06:03 -0800 Received: by wa-out-1112.google.com with SMTP id k34so491953wah.10 for ; Wed, 30 Jan 2008 10:06:03 -0800 (PST) Received: by 10.115.108.1 with SMTP id k1mr1167495wam.141.1201716362389; Wed, 30 Jan 2008 10:06:02 -0800 (PST) Received: by 10.115.107.7 with HTTP; Wed, 30 Jan 2008 10:06:02 -0800 (PST) Message-ID: Date: Wed, 30 Jan 2008 18:10:00 -0000 From: "Doug Evans" To: "Eli Zaretskii" Subject: Re: RFC: new command to search memory Cc: gdb-patches@sourceware.org, pkoning@equallogic.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080115221425.AF8591C7245@localhost> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00807.txt.bz2 On Jan 28, 2008 11:58 AM, Eli Zaretskii 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.