Re: [RFC stub-side break conditions 1/5] Documentation bits

[Pedro Alves <alves dot ped at gmail dot com>]

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?