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]

Re: Runtiming hw watchpoints; Was: Split up Z packet enable/disable cmd


Eli Zaretskii wrote:
> 
> [Sorry, pressed "Send" too soon...]
> 
> Current code tries to ask this question each time the user adds a
> watchpoint.  Since there's no way to answer that question accurately,
> I opted for the safe alternative: if there's *any* chance that a
> watchpoint *could* be inserted, go32-nat.c says YES, and leaves the
> final judgement to resume time.  The result is that the user could see
> "cannot insert watchpoint" when she says "continue".  However, this is
> better than refusing to accept a hw watchpoint when in fact it could
> be inserted.
> 

Well, breakpoint.c counts the numbers of things already set each time and even
accounts for enable/disable (as well as create/delete).  We can improve this
part if necessary.

See breakpoint.c (hw_breakpoint_used_count, hw_watchpoint_used_count)

Here is the change (note that the number of hw breakpoints has been included):

  if (mem_cnt != 0)
    {
+     j = hw_watchpoint_used_count ();
      i = hw_watchpoint_used_count (bp_type, &other_type_used);
      target_resources_ok =
!       TARGET_CAN_USE_HARDWARE_WATCHPOINT (bp_type, j, i + mem_cnt,
                                            other_type_used);
      if (target_resources_ok == 0 && bp_type != bp_hardware_watchpoint)
        error ("Target does not support this type of hardware watchpoint.");

      if (target_resources_ok < 0 && bp_type != bp_hardware_watchpoint)
        error ("Target can only support one kind of HW watchpoint at a time.");
    }


> If we agree that it is impossible for the target to know whether a
> given set of watchpoints can be inserted unless it knows about all the
> breakpoints and watchpoints, we need a way for the GDB application
> code to pass all that info, and hear the answer, before it resumes the
> debuggee.

But we know that (see above).  What we don't know if the particular target we
are connecting to is able to set those for us.  That is why we cannot tell for
sure before connecting (unless the user has explicitly told us so).

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

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