Re: [rfc target-side break conditions 1/5 v2] Documentation bits

[Stan Shebs <stanshebs@earthlink.net>]

On 1/27/12 12:33 PM, Luis Gustavo wrote:
> This is the second iteration of the documentation bits.
>
> I've switched to using explicit markers for the breakpoint parameters 
> in the Z packet.  Conditions will be passed via the "conditions" 
> marker, like the following:
>
> Z0,addr,kind,length,conditions=<cond1>;<cond2>;...;<condn>
>

I reviewed the prior discussion on protocol, and it wasn't clear to me 
why we couldn't use the same semicolon/colon syntax as is used for 
tracepoint packets, data packets, etc.  It would look like this:

Z0,addr,kind,length[;conditions:<cond1>,<cond2>,...]

Also, in the patch:

-@itemx Z0,@var{addr},@var{kind}
+@itemx Z0,@var{addr},@var{kind},@r{[}conditions=@var{cond-expr0};@var{cond-expr1};@dots{};@var{cond-exprn}@r{]}
  @cindex @samp{z0} packet
  @cindex @samp{Z0} packet
  Insert (@samp{Z0}) or remove (@samp{z0}) a memory breakpoint at address
@@ -34208,6 +34272,11 @@ A memory breakpoint is implemented by re
  the breakpoint in bytes that should be inserted.  E.g., the @sc{arm}
  and @sc{mips} can insert either a 2 or 4 byte breakpoint.  Some
  architectures have additional meanings for @var{kind};
+@var{cond-exprn} is an optional list of conditional expressions in bytecode
+form that should be evaluated on the target's side.  These are the
+conditions that should be taken into consideration when deciding if
+the breakpoint trigger should be reported back to @var{GDBN}.


You and I know that the cond-expr syntax is something like "X<hex 
digits>", but we should actually say that.  (And are we doing a bytecode 
count, or looking for an end-of-bytecodes char?)

Stan