This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 01/06/2012 02:22 PM, Pedro Alves wrote:
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?
I wasn't going to touch them for now, but i suppose they can be easily extended later on.


  @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]...’
Not right, i'll fix it in the next iteration after clearing the packet format issue.


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?

Makes sense. The problem is that each conditional expression is of the form "size,expr". That's why i used a different marker to signal the beginning of an extension area.


We could name each extension with a marker (cond, thread_id, itset etc...). Would it be too much overhead in the packet? Like the following.

Z0,addr,kind,cond=size0,expr0;size1,expr1;...;sizen,exprn,itset=<itset>,foo=<foo>...

Something that comes to mind regarding adding multiple extensions to these packets is the packet size limitation. We may have to add "continuation" packets if the extensions get too numerous. If that happens, it probably wouldn't be wise to rely on specific field ordering.

--
Luis
lgustavo@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]