This is the mail archive of the gdb-patches@sources.redhat.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]
Other format: [Raw text]

Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT


   Date: Thu, 22 Apr 2004 17:07:34 +0200
   From: Orjan Friberg <orjan.friberg@axis.com>

   Orjan Friberg wrote:
   > 
   > Agreed.  I am quite happy to live with your suggested solution, at least 
   > for now.  I certainly don't have the audacity to suggest such changes 
   > should be made to accomodate a target that isn't even submitted yet ;) .

   ... which brings me back to the reason for re-opening this thread:
   getting Paul Koning's patch to make read/access watchpoints work
   when HAVE_NONSTEPPABLE_WATCHPOINT is defined accepted.

   I did change one thing in Paul's patch, which should be
   highlighted: the change in bpstat_stop_status previously applied to
   bp_watchpoint types also (in addition to bp_hardware_watchpoint,
   bp_read_watchpoint, and bp_access_watchpoint), but as far as I can
   tell target_stopped_data_address applies only to hardware-assisted
   watchpoints, not software watchpoints.  Maybe that needs to be made
   more clear in the comment.

   Comments?

This patch breaks hardware watchpoints in SVR4-derived systems.  Those
systems don't provide target_stopped_data_address().  The default
target_stopped_data_address() will always return zero, which means
that triggered watchpoints aren't properly caught.  This results in
spurious SIGTRAPS.

Providing target_stopped_data_address() for the SVR4 proc(4) should be
possible, but its a risky bussiness, since there are several slight
variations of that interface.

   2004-04-22  Orjan Friberg <orjanf@axis.com>

	   From Paul Koning <pkoning@equallogic.com>:
	   * breakpoint.c (free_valchain): New function.
	   (insert_bp_location, delete_breakpoint): Use free_valchain.
	   (remove_breakpoint): Do not remove the valchain.
	   (bpstat_stop_status): If not stopped by watchpoint, skip
	   watchpoints when generating stop status list.
	   * infrun.c (handle_inferior_event): Make
	   stepped_after_stopped_by_watchpoint a global variable.
	   * remote.c (remote_stopped_data_address): Return watch data
	   address rather than zero if stepped_after_stopped_by_watchpoint is
	   set.

Anyway.  The problem is clearly that the whole target-specific
interface for hardware watchpoints is a mess.  We should really try to
*design* a proper interface instead of continuing to tweak the
existing interfaces.  Any people interested in makeing a proposal?

Mark


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