[RFC stub-side break conditions 1/5] Documentation bits
Pedro Alves
alves.ped@gmail.com
Fri Jan 6 16:22:00 GMT 2012
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?
More information about the Gdb-patches
mailing list