This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]