From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18215 invoked by alias); 23 Aug 2002 21:57:42 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18207 invoked from network); 23 Aug 2002 21:57:41 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 23 Aug 2002 21:57:41 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 826AFB8035; Fri, 23 Aug 2002 17:57:40 -0400 (EDT) Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id g7NLvev11512; Fri, 23 Aug 2002 17:57:40 -0400 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc/rfa:doco] Revised Z packet spec References: <3D669A90.50401@ges.redhat.com> Content-Type: text/plain; charset=US-ASCII From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 23 Aug 2002 15:02:00 -0000 In-Reply-To: <3D669A90.50401@ges.redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 X-SW-Source: 2002-08/txt/msg00774.txt.bz2 cagney wrote: > [...] > * gdb.texinfo (Packets): Revise `z' and `Z' packet documentation. > (Packets): Add cross reference from `b' packet to `z' packets. > ! [...] To avoid potential problems with duplicate packets, the > ! operations should be implemented in an idempotent way. What's the intent of this? To what extent do you think these packets need to be any differently idempotent from all the others? > ! Insert (@code{Z0}) or remove (@code{z0}) a memory breakpoint at address > ! @code{addr} of size @code{length}. > ! [...] > ! @emph{Implementation note: It is possible for a target to copy or move > ! code that contains memory breakpoints (e.g., when implementing > ! overlays). The behavior of this packet, in the presence of such a > ! target, is not defined.} Does this imply a promise by gdb that it will not make undefined protocol calls? - FChE