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

[Todd Whitesel <toddpw at windriver dot com>]

> 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.

Basically what I need is the moral equivalent of a "user" field tacked
onto every breakpoint struct.

Based on my existing code, the contents of this field would be:

	UINT32	breakpointID;	/* WTX-supplied handle for this breakpoint */
	bool	is_foreign;	/* true if breakpoint was set by someone else */
	bool	is_global;	/* true if breakpoint active for all tasks */

The is_foreign field is an interesting concept which I don't think anyone
else has implemented; it signifies a breakpoint that GDB does not "own".
One of the events I can receive from the target is "foreign breakpoint
created" and I find a safe time to call "break *<address>" in order to
let the breakpoint show up properly in GDB.

Foreign breakpoints look like normal breakpoints to GDB users except that
if they aren't recreated (new breakpoint struct allocated) by GDB commands,
then they are still marked "foreign" and when GDB exits they will not be
automatically removed. This is because some other command session usually
still exists, which created that breakpoint, and expects it to remain set
unless explicitly deleted by a user.

-- 
Todd Whitesel
toddpw @ windriver.com