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: minimalistic MI catch support


On Fri, Feb 10, 2006 at 08:40:30PM +0200, Eli Zaretskii wrote:
> > > > [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");
> 
> Yes, I was fooled by a similar code that does the same for
> bp_catch_catch (which I thought was run for "catch catch", whose
> address _is_ displayed).  Also, to _not_ print when the variable
> addressprint is non-zero doesn't really help to read the code, and the
> comment (repeated N times elsewhere) doesn't really explain anything,
> IMHO.

If addressprint is not set, nothing will print addresses, not even
breakpoints.  If it is set, then breakpoints will print addresses,
and catchpoints will explicitly skip the field.

> Anyway, if there's no meaningful address in this case, then we
> shouldn't print one for "catch catch", either.

For "catch catch" there is a relevant address, if breakpoints
are used to implement it.  Still, I've got no objection to skipping it
for consistency.  Unless GDB makes a mistake, the address is
irrelevant.

> I take it that this is
> currently hard to do, since there's no sign in the breakpoint data
> structure that this breakpoint is special, right?  I guess this all
> boils down to adding two more bp_* enum members, one each for the
> new-style catch and throw breakpoints.  Then the print routines will
> know to DTRT (and the code will be clearer as well).

No, not at all.  It's not hard to do currently; that was part of my
point in object-ifying this.  If you scroll a page or so up, to before
that big switch statement, you'll find:

  if (b->ops != NULL && b->ops->print_one != NULL)
    b->ops->print_one (b, last_addr);

Of course, it's called after the description field has been printed. 
So we've got the option of adding a description string to the
breakpoint ops, or making print_one duplicate more of the work of
print_one_breakpoint; I think the former is probably the way to go.

  if (b->ops && b->ops->description)
    print it
  else
    current table lookup

> > > >   - 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.
> 
> You are talking about watching expressions, and you are talking
> intermittently about high-level and raw watchpoints.  I was thinking
> only about raw watchpoints we insert on the target side, thus the
> misunderstanding.

We were talking about the bp_* constants, the "struct breakpoint",
and the "struct bp_location".  These are all mapped to "high level"
breakpoints at the moment - whether they should be or not is another
question.

> So do you suggest to show all the raw watchpoints used to watch an
> expression?  That could mean an awfully large list of addresses.

Hardly, compared to breakpoints on inlined functions.  If anything, I'd
propose to treat these the same way we ought to treat those: if there
isn't a sensible address, don't show one, and allow the user to drill
down and see the set of addresses that make up their breakpoint if they
want to.

> I don't see why not display for the watchpoints the address of the
> first value on the value chain.  This will at least show the right
> address when the expression is actually a simple variable.  WDYT?

*shrug* No opinion.

-- 
Daniel Jacobowitz
CodeSourcery


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