Re: minimalistic MI catch support

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Feb 10, 2006 at 01:25:28PM +0200, Eli Zaretskii wrote:
> > 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.

> I think this is a bug (or undocumented misfeature) in
> breakpoint.c:handle_gnu_v3_exceptions.  You will see that it sets the
> type of the raw breakpoint it creates to bp_breakpoint, instead of
> using the argument ex_event that is passed by the caller.  In
> addition, for some reason, it forces a special function to be used for
> printing these catchpoints, and that function
> (print_one_exception_catchpoint) doesn't use the list of descriptions
> in the bptypes[] array used by the more general code in
> print_one_breakpoint.  I think it's bad to have more than one place to
> have these description strings.

That's not a bug, it's supposed to be a progression!  The idea was to,
over time, make the breakpoint layer more object-oriented.  Just
because no one has had time to go back to it yet...  One of my goals
was to break up the huge switch statements on breakpoint type.

ex_event is not suitable for two reasons; one is that EX_EVENT_CATCH
has little direct relationship to the bp_* constants, and the other is
that the type of the breakpoint is used to handle it, e.g. in
bpstat_stop_status.  "catch fork" is handled by a system event; on old
HP systems, "catch throw" was too, which I suspect is why it was
implemented as a catchpoint.  But on GNU systems, EH catchpoints are
just magical breakpoints in the runtime library.  Ideally, after
hitting them, we change frames a little ways up into the user's code;
IIRC that's not implemented because of some problem I had getting
it to work, but I can't remember the details.

As background, the overall reason for making it more object oriented is
the distinction between "what the user asked for" and "how gdb
satisfies that request".  For instance, a longstanding shortcoming in
my humble opinion is that GDB can't use hardware breakpoint resources
automatically - there's code that associates things like "bp_longjmp"
with "oh, that's really a bp_breakpoint and I'll handle it like one",
instead of information in the breakpoint that says "oh, this is really
a software breakpoint".

That's not 100% true any more now that I added bp->loc->loc_type, which
explicitly says the breakpoint has type bp_loc_software_breakpoint. 
But the two are not yet fully decoupled.

I'm not sure what "info breakpoints" should have to say about it;
whether it should show the underlying implementation and address,
or hide them as if it were a true catchpoint.  If Nick's got a
convincing argument to display "catchpoint" instead of "breakpoint",
I'm sure we can change that.

> Can someone explain why we should use special code for gnu_v3
> exceptions?

I hope the above covers this.

> As for the address not being printed, can you step with a debugger
> through the function that prints these breakpoints and see why they
> are skipped?  I cannot for the moment see any reason, just looking at
> the code.

[Now we're talking about fork catchpoints rather than EH.]

There's no meangingful address.  See this in breakpoint.h:

  /* Note that zero is a perfectly valid code address on some platforms
     (for example, the mn10200 (OBSOLETE) and mn10300 simulators).  NULL
     is not a special value for this field.  Valid for all types except
     bp_loc_other.  */
  CORE_ADDR address;

That's used for:

  - Software watchpoints.  I still plan someday to finish refactoring
    this so that a single watchpoint, software or otherwise, has
    multiple bp_location entries, each with a valid address.  But there
    will still be some software watchpoints that don't, e.g. I believe
    it is possible to set a software watchpoint on the value of a
    register.
  - Fork, vfork, and exec catchpoints.
  - Catch and throw catchpoints, if their type is bp_catch_*, which it
    is for the non-GNU implementation, which hasn't been tested in
    years.

The last two are associated with system events, just like DLL events
in Windows, not with a specific PC.

-- 
Daniel Jacobowitz
CodeSourcery