gdb stops with too many watchpoints when there is only one

Do you know any other reasons why a watchpoint could not be inserted other than too many hardware breakpoints/watchpoints?

I have the following debug session:

GNU gdb (GDB) 7.1
...
(gdb) watch itrap_t_beg[1][222]
Hardware watchpoint 1: itrap_t_beg[1][222]
(gdb) cont
Continuing.
...
Hardware watchpoint 1: itrap_t_beg[1][222]

...
(gdb) cont
Continuing.
Warning:
Could not insert hardware watchpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

(gdb) info break
Num     Type           Disp Enb Address            What
1       hw watchpoint  keep y                      itrap_t_beg[1][222]
        breakpoint already hit 1 time

As you can see, there's only one watchpoint yet it can't insert the breakpoint.

Do you know h开发者_Go百科ow can I fix this?

As far as I know commodity x86 CPUs have four debug registers available for supporting hardware breaks/watches. This limits the object size that you can watch. Object alignment also plays here.

Try limiting the watch scope to a smaller object like pair of first and last members of the structure.

Can force software breakpoints (which do not have limit on size) by running

set can-use-hw-watchpoints 0

Shot answer: Use watch -location itrap_t_beg[1][222], or the short form watch -l.

Long answer: Quoting the GDB manual:

Watching complex expressions that reference many variables can also exhaust the resources available for hardware-assisted watchpoints. That's because gdb needs to watch every variable in the expression with separately allocated resources.

gdb quite literally watches the expression itself, not whatever address it points to. In this case, it means that the breakpoint will hit if itrap_t_beg itself is changed such that itrap_t_beg[1][222] does; there's not just a watchpoint for itrap_t_beg[1][222], but also one for itrap_t_beg itself. This may be more than what's available.

In your case, itrap_t_beg is 7 ints, 28 bytes. A x86_64 watchpoint is up to eight bytes, so GDB needs four watchpoints for the entire structure - plus a fifth for itrap_t_beg itself. The x86 family only supports four simultaneous watchpoints.

A more comprehensive example on how watchpoints work:

//set a watchpoint on '*p' before running
#include <stdio.h>
int a = 0;
int b = 0;
int c = 0;
int* p = &a;

int main()
{
    puts("Hi"); // Dummy lines to make the results clearer, watchpoints stop at the line after the change
    *p = 1; // Breaks: *p was changed from 0 to 1
    puts("Hi");
    a = 2; // Breaks: a is *p, which changed from 1 to 2
    puts("Hi");
    p = &b; // Breaks: p is now b, changing *p from 2 to 0
    puts("Hi");
    p = &c; // Doesn't break: while p changed, *p is still 0
    puts("Hi");
    p = NULL; // Breaks: *p is now unreadable
    puts("Hi");
    return 0;
}

In theory, this is a useful feature; you can watch a complex expression, breaking as soon as it's false, somewhat like a constantly-tested assertion. For example, you can watch a==b in the above program.

In practice, it's unexpected, often triggers this issue, and usually isn't what you want.

To watch only the target address, use watch -location itrap_t_beg[1][222]. (This is available as of GDB 7.3, released in July 2011; if you're still on 7.1, use print &itrap_t_beg[1][222] and watch *(itrap_t)0x12345678, or whichever address it prints.)