From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1345 invoked by alias); 6 Feb 2004 17:02:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1329 invoked from network); 6 Feb 2004 17:01:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 6 Feb 2004 17:01:56 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 812362B92; Fri, 6 Feb 2004 12:01:55 -0500 (EST) Message-ID: <4023C883.6010407@gnu.org> Date: Fri, 06 Feb 2004 17:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Roland McGrath Cc: gdb@sources.redhat.com Subject: Re: remote protocol support for TARGET_OBJECT_AUXV References: <200402060249.i162nP8R009810@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00059.txt.bz2 > I think these improvements are worth pursuing without delay. However, I > don't see any reason not to go ahead with the protocol you have proposed in > the interim, since I can implement that in a few minutes without perturbing > anything else. OK. Once we've seen the numbers we can persue this. >> -> qPartial:? >> <- OK -- queries of type are supported >> <- "" -- queries of type are not supported > What does "supported" here mean exactly? A stub will e.g. support reading > but not writing, and a very constrained range of "annex" values. If an OK > response to "qPartial:foo?" just means that you have some chance if you try > some particular read/write query, is there a particular benefit to that > over just trying the first query you wanted and taking the empty reply as > "not supported"? Good question. In the past GDB has encountered situtations where it needed to differentiate between the questions: - operation not supported - error during supported operation for instance, with breakpoints, with the current protocol there's no well defined mechanism for determining if: -> Z2,0,0 or -> Z2 <- E00 (insert watchpoint,addr,len) fails because: - 0,0 is an illegal addr,len - Z2 is, in that stub, considered an illegal Z packet - the operation is legal, but the hardware failed The proposal is to fix it with: -> Z2? <- OK so that GDB can explictly differentiate between: - hardware watchpoints not supported - error inserting hardware watchpoint consequently, since then, care as been taken to define a "supported" query with new packets. For here, the cases I can think of are: - new gdb, old stub, packet not recognized "" must always be returned - new gdb, new stub, no /proc, or no read(write?) /proc access Operation attempted, Enn returned - new gdb, new stub, /proc Operation attempted, valid response returned so perhaphs clearly specifying this may prove sufficient. I think that the main thing is that the spec has to be clear that: -> qPartial:asdfasdf:... <- "" where "asdfasdf" is not "supported" must return "" and not "Enn". >> a variation being something like: >> qPartial:obj=:op=write[:annex=]:offset=:data= >> which makes it more extensible. > > > That is not really any more extensible, I'd say. You can just define new > tokens after the first or second : to change the details later. This is > just more verbose, unless it's free form as to the order of parameters. > Being free form is less desireable because it requires hairy parsing in the > stub instead of just matching fixed leading strings for the few particular > requests that are actually supported. Should additional parameters be needed, it might help. However, yes, simply specifying a new packet is easier. Andrew PS: A contraction would be 'qPart:...".