Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> One aspect of this gives me cold feet and sweety palms.
> Andrew> You're giving the target code access to the entire bp struct.
> Andrew> While I don't have any problems with handing the code a
> Andrew> breakpoint handle, I have strong reservations towards any
> Andrew> moves that give the target unfettered access to the entire
> Andrew> ``struct breakpoint''.  We'll be spending the next 10 years
> Andrew> trying to get control back again :-)
> 
> I appreciate this argument, and agree that the target interface should
> be as robust as possible.  After reading your message, I thought about
> hiding the fact that the argument is a struct breakpoint pointer and
> providing macros to access "public" fields, but any subversion we do
> can be undone by a clever programmer.  I'm still working on something
> that is simple, elegant, and efficent.

In the case of gdbarch, everything is manipulated via methods.  Each
legacy macro is backed by a C function.  The programmer does not have
direct access to the gdbarch object.

GDBARCH set a very very high standard (possibly too high).  However,
whats interesting is the problems so far identified have related to
things like defaults and not to the actual interface.

> However, I think it's a bit of a stretch to say such changes in and of
> themselves will lead to GDB being out of control.  IMHO, this can only
> happen if the GDB maintainers fail to do their jobs and integrate code
> that disrupts GDB's architectural integrity.  I'll stipulate that
> we've done a rather poor job of this in the past, but I'm hopeful that
> attitudes have changed.

I'm looking at it from the view of what is involved in making a change
to ``struct breakpoint''.  If targets directly depend on random bits
than that change becomes that much harder.

If target code can poke around with ``struct breakpoint'' internals then
there is that extra bit of pressure to let through that patch which
solves the problem that everyone is concerned about but no one has a
clean fix for.

> Andrew> I'd prefer to see something that tightens rather than loosens
> Andrew> access to ``struct breakpoint''.  Perhaphs something along the
> Andrew> lines of multi-arch where the target is notified of breakpoint
> Andrew> create, insert, remove, delete operations.

Possibly a side issue.  When a new architecture is created.  gdbarch
notifies all interested parties so that they can update their local
architecture specific information.  See gdbtypes.c for a very good
example.

If the target wants to know about breakpoint changes then notify it
(mumble something about the observer pattern).

	Andrew