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.)
- To: ac131313 at cygnus dot com (Andrew Cagney)
- Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
- From: Todd Whitesel <toddpw at windriver dot com>
- Date: Thu, 9 Mar 2000 17:28:00 -0800 (PST)
- Cc: jtc at redback dot com, gdb at sourceware dot cygnus dot com (GDB)
> 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