Re: minimalistic MI catch support

[Nick Roberts <nickrob@snap.net.nz>]

 > > > The second two have their own type: "catch fork" and "catch exec" (I
 > > > must admit that I don't understand how this gives differerent behaviour
 > > > from using "break fork" and "break exec").
 > 
 > They are associated with the system events reported for fork and exec. 
 > That means that in addition to the above, they'll catch things like
 > clone with appropriate arguments, execlp, direct use of syscall()...
 > 
 > Also, they give GDB external knowledge about what's going on, enabling
 > it to track the child of the fork, or the target of the exec.  That
 > latter is currently disabled because the code and user interface
 > for following exec were such a mess.
 > 
 > > >  Also for some reason, they have no address.
 > 
 > Unlike a breakpoint, they are associated with an event and not an
 > address.  They aren't at all like breakpoints.

OK thanks for explaining the difference.  I would still say that they are
a _bit_ like breakpoints (they stop execution if fork or exec are called)
and I guess thats why their details are given in "info breakpoints".

Are you saying "catch fork" and "catch exec" aren't at all like
"catch catch" and "catch throw" which do have addresses?  If so, perhaps
some clearer distinction could be made to the user/in MI output.

Nick