From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4035 invoked by alias); 29 Feb 2008 03:13:16 -0000 Received: (qmail 4025 invoked by uid 22791); 29 Feb 2008 03:13:15 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Feb 2008 03:12:56 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id EE93A983A1; Fri, 29 Feb 2008 03:12:53 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C766398140; Fri, 29 Feb 2008 03:12:53 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JUvg4-0000ps-Lc; Thu, 28 Feb 2008 22:12:52 -0500 Date: Fri, 29 Feb 2008 03:58:00 -0000 From: Daniel Jacobowitz To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFA] new command to search memory Message-ID: <20080229031252.GA2897@caradoc.them.org> Mail-Followup-To: Doug Evans , gdb-patches@sourceware.org References: <20080214021915.F3FE51C72F0@localhost> <20080226022335.GB4456@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) 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-02/txt/msg00490.txt.bz2 On Thu, Feb 28, 2008 at 06:44:00PM -0800, Doug Evans wrote: > > The slashed arguments work analagously to x and display, which is > > nice. Should the default count should be one instead of infinity? > > I suppose having it default to infinity is nice, since we don't > > have to invent a syntax for infinity that way. > > /u or some such for "unlimited" would work I guess. I can change the > default if that's preferable. I think it's fine the way you've got it. > > What do you think of "+" instead of "@" to distinguish lengths? "find > > &hello[0] +0x100". > > I picked "@" because it's used, for example, in "p foo[0]@10". It's > not identical, but it seemed similar enough. "+" works too. I'd prefer +, if that works for you. > Ya, but for completeness sake it's not just the malloc call, it's the > whole shebang. I can understand why in > > (gdb) p strcmp (foo, "bar") > > one wants to download "bar" to the target before calling strcmp, but > find's needs are different. Right. I've got a patch to cover the downloading. I didn't get it posted yet but it hasn't dropped off my list for this week either. > > qSearch:memory does not need to be advertised for qSupported. The > > rule of thumb is that things which are used to implement a user > > command don't need to be, since there's no big penalty if we try them > > and are told they are not supported - we'll just try another approach > > and next time we'll know. That means you need to handle > > PACKET_DISABLE twice, before and after sending the packet. > > I found a use for the option that goes with qSupported both for > testing and analysis. Maybe users would also find use for the choice, > but it can be tossed. The option isn't actually linked to qSupported; you can add just the option, and it will default to auto. > > > +If the value size is not specified, it is taken from the > > > +value's type. This is useful when one wants to specify the search > > > +pattern as a mixture of types. > > > > IMO this will confuse users for constants, which have type int (or > > sometimes long), so could you add a word about that? Otherwise > > someone will type "find &hello[0], @100, 0x65, 0x66" and be confused > > by the lack of matches. > > Or one could default to something else, bytes or ints or some such, > and have a /t option or some such that says to use the type of the > object. Either way; I've no preference. The way you've got it seems fine if we can clarify the description. -- Daniel Jacobowitz CodeSourcery