Re: RFA: Breakpoint infrastructure cleanups [0/8]

["Eli Zaretskii" <eliz at elta dot co dot il>]

> Date: Thu, 16 Oct 2003 10:25:26 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> BTW, long term, this stuff is going to be hijacked by other *point 
> mechanisms.  Variable watchpoints, for instance, will be given a similar 
> projection (the watchpoint changes that last year stalled can probably 
> be picked up again).  While the term "breakpoint" may continue to be 
> used, it will be applied to more than just breakpoints.

I don't see any problems with that.  In fact, we might wish to start
educating GDB users to use the term ``breakpoint'' for all of those.
E.g., many implementations of dbx and other debuggers support
watchpoints, but call them ``breakpoints'' or ``data breakpoints''.
Someone whose first debugger was GDB might not even find how to set
watchpoints unless they try looking for "breakpoint".

In other words, we actually set a trap in each of these *point
situations, so they are really very much alike.  Therefore, it comes
as no surprise that they share many similar features and are all
described by struct breakpoint.

> (Happened to talk to fernado about his uni GDB work and he explained 
> that that the logical/physical separation occures all over the place - 
> happened to also use log/phys without my prompting :-).

I actually think that we should leave the term ``breakpoint'' alone,
and refer to what you call ``a physical breakpoint'' as the
breakpoint's location or instantiation.  That's because most of the
information associated with a breakpoint is stored with the ``logical
breakpoint'', whereas the ``physical breakpoint'' only stores an
address and a bunch of flags.