This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
"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