Re: [PATCH 1/2] Global breakpoints, GDB part

[Stan Shebs <stanshebs at earthlink dot net>]

On 6/13/11 11:55 AM, Eli Zaretskii wrote:
> > Date: Mon, 13 Jun 2011 09:10:52 -0700
> > From: Stan Shebs<stanshebs@earthlink.net>
> >
> > This pair of patches plus Linux kernel module adds global breakpoints to
> > GDB.
> > +                                 However, @value{GDBN} will not insert
> > + global breakpoints into its own process, nor any process that is under
> > + a debugger's control.
> "a debugger's control"?  Is this correct English?

Sure, seems uncontroversial to me.  If we don't like the possessive, 
then it could be phrased "under the control of a debugger."  The intent 
is to make clear that GDB is not going to contest with other debuggers 
for control of a process.

> > + If the current inferior is included in @var{processes}, then the
> > + breakpoint also acts as a normal breakpoint for the inferior.
> Not clear what you mean here.  What is "current inferior" in this
> context, and how is the breakpoint different from a "normal" one if
> the current inferior is not included in the list?

By "current inferior" I mean the process currently being debugged.  It's 
different from a normal breakpoint because if you detach from the 
process, the global breakpoint is re-installed, and you will get a 
re-attach if the global breakpoint is hit again.  (Global breakpoints 
only go away if you deleted them explicitly, or if you quit GDB.)

> > + Global breakpoints remain in effect after you detach from a process.
> Which one?  There could be several.

All global breakpoints remain in effect, even if you are attached to 
several processes and detach from just one of them.

> > + The process specification is basically a comma-separated list of pids
> > + and wild cards.  The specification may not have any whitespace
> > + embedded.
> Ouch! why is whitespace disallowed?

It's a general lameness of breakpoint command syntax.  The problem is 
that if you allow whitespace in arguments, you can't reliably 
distinguish a thread named "if" from the keyword "if".  This 
multiple-process syntax is the most complicated that is not the full 
conditional expression, so it hasn't been an issue before now.

I'm happy to entertain alternative suggestions - although the original 
RFC from last year ( http://sourceware.org/ml/gdb/2010-05/msg00019.html 
) describes this proposed syntax, but there's no mention of the 
whitespace limitation.

> > + @item /*
> > + Says the specification applies to all users' processes.
> Why the slash?

No deeper reason than that it vaguely suggests urls/homedirs, I'm open 
to alternatives.

Stan
stan@codesourcery.com