This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: A patch for ia32 hardware watchpoint.
- To: toddpw at windriver dot com
- Subject: Re: A patch for ia32 hardware watchpoint.
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Thu, 9 Mar 2000 08:28:13 -0500 (EST)
- CC: jtc at redback dot com, hjl at valinux dot com, gdb-patches at sourceware dot cygnus dot com, gdb at sourceware dot cygnus dot com
- References: <200003080845.AAA18410@alabama.wrs.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> As far as I'm concerned, passing the breakpoint pointer is the right way
> to go; we should get away from the assumption that a target side breakpoint
> is an address with some #define'd size, and push that stuff into a default
> implementation that can be invoked easily by people writing new target
> support.
I agree.
But if we do that, I'd also suggest to leave it to the target to
decide whether a particular watchpoint fired or not.
Right now, the API presented by GDB is based solely on the address:
bpstat_stop_status calls target_stopped_data_address and does all the
decision-making based solely on that address (and some info it keeps
internally about each watchpoint).
This API is extremely limited. Typically, the target knows much more
about the watchpoint which triggered than the generic GDB code does,
so it can make smarter decisions. But in order to do that, the target
needs more information about the watchpoint, and it needs to pass back
to GDB the result (whether the watchpoint triggered or not), not its
address.
Btw, if we let the target decide whether a given watchpoint triggered,
we can also resolve, once and for all, all the various conflicts
between target-specific limitations of hardware-assisted watchpoints,
which now need to be dealt with on the generic level.