minimalistic MI catch support

Daniel Jacobowitz drow@false.org
Fri Feb 10 16:48:00 GMT 2006


On Fri, Feb 10, 2006 at 05:41:18PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 10 Feb 2006 09:11:38 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Nick Roberts <nickrob@snap.net.nz>, gdb-patches@sourceware.org
> > 
> > > 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
> 
> Which part?  I was talking about two things, not one, and only called
> the first one a possible bug.

Well, I was responding to "I think this is a bug in", which I
associated with "You will see that".

> > ex_event is not suitable for two reasons; one is that EX_EVENT_CATCH
> > has little direct relationship to the bp_* constants
> 
> ??? Isn't there a 1:1 correspondence between them?

Nope.  I agree this is unclear.

EX_EVENT_CATCH means "the user has asked for a 'catch catch'
operation".  bp_catch_catch means "we have set an OS-specific
catchpoint on the 'an exception has been caught' event".  In
the original case, these two did correspond; but for modern C++ ABIs
(ignoring the issue of Windows SEH here for the moment...) they no
longer correspond, and there is no event external to the process
that we can capture.  Instead, we set a breakpoint at an ABI-defined
location.

It Might Be Nice If the bp_catch_catch event described the user's
intent and its ->loc described the implementation.  I'm not sure.
Anyway, the two are not yet sufficiently separated.

> Thanks for the explanations, but I still cannot see what does this
> have to do with the issue at hand.  The issue at hand is consistency
> of the UI.  IMHO, the details of the implementation do not matter from
> UI's point of view; whatever hoops GDB is jumping through behind the
> scenes, we should still present the same consistent UI to the user.
> That means the format we use to report all the catchpoints should be
> the same no matter how those catchpoints are implemented.
> 
> In other words, we should use the our knowledge about these
> breakpoints being ``magical'' to present a consistent view to the
> users on all systems.

Well, you asked about the non-use of bp_catch_catch :-)  That's the
implementation.  I've got no objection to changing the info breakpoints
output to describe them as catchpoints, if that's considered superior.

> > 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.
> 
> The latter, IMO; the former is suitable for a "maint" command, not for
> a user-level command.

Hmm.  Good idea.  I don't think it really fits into "maint info
breakpoints" at the moment, but maybe we can rearrange... I think
we ought to defer this until the one-to-many breakpoint issues are
finally addressed, which will hopefully be this year.

> I'd suggest some comments saying that this area is in flux and that
> the intent is to make all the bp_* types look like catch and throw.
> Otherwise, it's impossible to know where we are aiming, and this could
> bite someone who will want to submit patches in that area.

That's a good idea.  I'll leave myself a note to write such, unless
someone else wants to.

> > > 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.
> 
> Yes, but what code knows about that? i.e. where in the code is it
> clear that the address isn't displayed?

For instance,

      case bp_catch_fork:
      case bp_catch_vfork:
        /* Field 4, the address, is omitted (which makes the columns
           not line up too nicely with the headers, but the effect
           is relatively readable).  */
        if (addressprint)
          ui_out_field_skip (uiout, "addr");
        annotate_field (5);
        if (b->forked_inferior_pid != 0)
          {
            ui_out_text (uiout, "process ");
            ui_out_field_int (uiout, "what", b->forked_inferior_pid);
            ui_out_spaces (uiout, 1);
          }
        break;

> >   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.
> 
> ??? Under what circumstances would a watchpoint have to have several
> locations?  It's watching data, and data has one address only, right?
> What am I missing?

Oh, there's plenty of examples.  Here's an easy one.  Suppose we have
an int **ptr, and the user sets a watchpoint on **ptr.  That's
implemented with two watchpoints: one on ptr, and one on *ptr.  When
ptr changes, the watchpoint on *ptr has to be moved.

We do this with both software and hardware watchpoints.

      case bp_watchpoint:
      case bp_hardware_watchpoint:
      case bp_read_watchpoint:
      case bp_access_watchpoint:
        /* Field 4, the address, is omitted (which makes the columns
           not line up too nicely with the headers, but the effect
           is relatively readable).  */

I'm not sure of the address field is used for hardware watchpoints
or not, actually, but in any case it is not displayed.  Just the
expression is.

-- 
Daniel Jacobowitz
CodeSourcery



More information about the Gdb-patches mailing list