From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-86842-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 21578 invoked by alias); 6 Jan 2012 16:22:37 -0000
Received: (qmail 21569 invoked by uid 22791); 6 Jan 2012 16:22:36 -0000
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 16:22:08 +0000
Received: by wibhq12 with SMTP id hq12so1733914wib.0        for <gdb-patches@sourceware.org>; Fri, 06 Jan 2012 08:22:07 -0800 (PST)
Received: by 10.180.88.229 with SMTP id bj5mr8293447wib.5.1325866927717;        Fri, 06 Jan 2012 08:22:07 -0800 (PST)
Received: from [192.168.0.103] ([2.82.184.26])        by mx.google.com with ESMTPS id ej17sm68823300wbb.14.2012.01.06.08.22.06        (version=SSLv3 cipher=OTHER);        Fri, 06 Jan 2012 08:22:06 -0800 (PST)
Message-ID: <4F071FAD.9050303@gmail.com>
Date: Fri, 06 Jan 2012 16:22:00 -0000
From: Pedro Alves <alves.ped@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: luis_gustavo@mentor.com
CC: gdb-patches@sourceware.org
Subject: Re: [RFC stub-side break conditions 1/5] Documentation bits
References: <4F05BA03.1010203@mentor.com>
In-Reply-To: <4F05BA03.1010203@mentor.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2012-01/txt/msg00239.txt.bz2

On 01/05/2012 02:56 PM, Luis Machado wrote:
> +@item @code{conditional-breakpoints-packet}
> +@tab @code{Z0 and Z1}
> +@tab @code{Support for stub-side breakpoint condition evaluation}
>   @end multitable

What about watchpoints, and other Z packets?

>   @node Remote Stub
> @@ -34149,7 +34206,7 @@ avoid potential problems with duplicate
>   be implemented in an idempotent way.}
>
>   @item z0,@var{addr},@var{kind}
> -@itemx Z0,@var{addr},@var{kind}
> +@itemx Z0,@var{addr},@var{kind};@r{[};@var{cond expr}@r{]}@dots{}
>   @cindex @samp{z0} packet

That seems to renders as ‘Z0,addr,kind;[;cond expr]...’

Hmm.  If we're reusing/extending Z packets, then I'd rather this doesn't
make it hard to support future extensions to the packet (e.g., thread specific
breakpoints), while at the same time _not_ supporting stub-side
condition evaluation.  So imagine that I'll add a new thread-id (pPID.TID)
field to this packet, and I will specify an empty condition.   How will the
result look like?

   Z0,addr,kind;;pPID.TID

?

Wouldn't it be better something like:

  Z0,addr,kind,cond_expr_list,other_future_extensions’

and cond_expr_list being a ;-separated list?