On 02/07/2012 07:41 PM, Stan Shebs wrote:
> 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?)

I've updated this and the documentation clearly states that each 
conditional expression is of the form "X<size>,<length>, with no 
separator between each conditional expression. I'm also using the new 
syntax.