From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: GDB Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Tue, 21 Mar 2000 02:50:00 -0000 Message-id: <38D753B9.23BC4B2D@cygnus.com> References: <200003080845.AAA18410@alabama.wrs.com> <5mitywc5ac.fsf@jtc.redbacknetworks.com> <38C834AD.3379D1F2@cygnus.com> <5m8zzl6w5r.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-03/msg00288.html "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: GDB Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <38D753B9.23BC4B2D@cygnus.com> References: <200003080845.AAA18410@alabama.wrs.com> <5mitywc5ac.fsf@jtc.redbacknetworks.com> <38C834AD.3379D1F2@cygnus.com> <5m8zzl6w5r.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00753.html Message-ID: <20000401000000.CPjYPAwkUa23MEy3QwrUQKav8XKrDxs6-G_v8bkOk0U@z> "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney 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