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


> 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.

> 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?

> 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.

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.

> 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.

> > Can someone explain why we should use special code for gnu_v3
> > exceptions?
> 
> I hope the above covers this.

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.

> > 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?

>   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?

>     I believe it is possible to set a software watchpoint on the
>     value of a register.

Yes, it's possible.  I've even used that once, I don't remember in
what situation, but I do remember that this was the only method to
track something tricky.


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