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:
>
> >>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> writes:
> jtc> I was planning to propose that the breakpoint pointer itself be passed
> jtc> to the target_{insert,remove}_{break,watch}point() functions, so this
> jtc> is as good of time as any.
>
> Todd> I say Just Do It. I am sitting on some local code here that tracks
> Todd> breakpoints added to the target by a third party, and I ended up needing
> Todd> the breakpoint shadow field to be available to those functions.
>
> I spent some time yesterday investigating what would be necessary to
> change the target_{insert,remove}_breakpoint() API to pass a pointer
> to struct breakpoint.
>
> What I have so far is change the API from:
> int foo_insert_breakpoint (CORE_ADDR addr, char *shadow_contents);
> to:
> int foo_insert_breakpoint (struct breakpoint *bp, CORE_ADDR addr);
J.T.,
One aspect of this gives me cold feet and sweety palms. You're giving
the target code access to the entire bp struct. While I don't have any
problems with handing the code a breakpoint handle, I have strong
reservations towards any moves that give the target unfettered access to
the entire ``struct breakpoint''. We'll be spending the next 10 years
trying to get control back again :-)
I'd prefer to see something that tightens rather than loosens access to
``struct breakpoint''. Perhaphs something along the lines of multi-arch
where the target is notified of breakpoint create, insert, remove,
delete operations.
Andrew