gdb/2499: to_can_use_hw_breakpoint/CAN_USE_HARDWARE_WATCHPOINT ambiguous

[jeremy.bennett@embecosm.com]

>Number:         2499
>Category:       gdb
>Synopsis:       to_can_use_hw_breakpoint/CAN_USE_HARDWARE_WATCHPOINT ambiguous
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 12 06:38:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     jeremy.bennett@embecosm.com
>Release:        unknown-1.0
>Organization:
>Environment:
Fedora 9 Linux, GDB 6.8, OpenRISC 1000 (or1k) target
>Description:
The code to set a watchpoint in watch_command_1() tests to see if a hardware watchpoint is available, using CAN_USE_HARDARE_WATCHPOINT, which in turn calls the to_can_use_hw_breakpoint() function of the target.

This returns 0 to indicate that the particular type of watchpoint is unsupported and -1 to indicate either that there are insufficient watchpoint resources or that two different types of watchpoint cannot simultaneously be supported. However for the latter case the error message given is always:

  "Target can only support one kind of HW watchpoint at a time."

This is confusing if the problem is actually that the resources have run out.

This bug is related to Bug 967, concerning the need to pass to_can_use_hw_breakpoint() additional information for it to make a good judgement.

Not a high priority, but entered here for the record.
>How-To-Repeat:
At present I can only demonstrate this with the GDB 6.8 port for the OpenRISC architecture, which supports a maximum of 4 watchpoints:

(gdb) rwatch a
Hardware read watchpoint 1: a
(gdb) rwatch b
Hardware read watchpoint 2: b
(gdb) rwatch c
Hardware read watchpoint 3: c
(gdb) rwatch d
Hardware read watchpoint 4: d
(gdb) rwatch e
Target can only support one kind of HW watchpoint at a time.
(gdb) 

It should occur for any architecture with finite hardware watchpoint resources.
>Fix:
I suggest to_can_use_hw_breakpoint() specification is extended to allow return -2 to indicate resources have run out with -1 reserved for its current meaning. The code in watch_command_1() could then be extended to print out the appropriate message in each case. This would be backwards compatible with the existing code base.

>Release-Note:
>Audit-Trail:
>Unformatted: