gdb se detiene con demasiados puntos de observación cuando solo hay uno

Question

¿Conoce alguna otra razón por la cual no se pudo insertar un punto de observación aparte de demasiados puntos de interrupción/puntos de observación de hardware?

que tienen la siguiente sesión de depuración:

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 

Como se puede ver, sólo hay un punto de observación, sin embargo, no puede insertar el punto de interrupción.

¿Sabes cómo puedo solucionar esto?

Answer 1

Por lo que sé, las CPU x86 tienen cuatro debug registers disponibles para soportar interrupciones/relojes de hardware. Esto limita el tamaño del objeto que puedes ver. La alineación de objetos también se reproduce aquí.

Intente limitar el alcance del reloj a un objeto más pequeño como el par del primer y último miembro de la estructura.

Answer 2

se puede obligar a los puntos de interrupción de software (que no tienen límite en el tamaño) mediante la ejecución de

conjunto can-uso-HW-0 puntos de observación

Answer 3

Shot Respuesta: Utilice watch -location itrap_t_beg[1][222], o la forma corta watch -l.

Respuesta larga: Quoting the GDB manual:

Observación de expresiones complejas que hacen referencia a muchas variables también pueden agotar los recursos disponibles para los puntos de observación asistidas por hardware. Eso es porque gdb necesita ver cada variable en la expresión con recursos asignados por separado.

gdb mira literalmente la expresión en sí, no importa la dirección a la que apunta. En este caso, significa que el punto de interrupción se activará si itrap_t_beg se cambia de manera que itrap_t_beg[1][222] sí lo hace; no solo hay un punto de observación para itrap_t_beg[1][222], sino también uno para itrap_t_beg. Esto puede ser más de lo que está disponible.

En su caso, itrap_t_beg es 7 ints, 28 bytes. Un punto de observación x86_64 tiene hasta ocho bytes, por lo que GDB necesita cuatro puntos de observación para toda la estructura, más un quinto para itrap_t_beg. La familia x86 solo admite cuatro puntos de observación simultáneos.

Un ejemplo más completa sobre cómo puntos de observación de trabajo:

//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; 
} 

En teoría, esto es una característica útil; Puedes ver una expresión compleja, rompiendo tan pronto como sea falsa, algo así como una afirmación constantemente probada. Por ejemplo, puede watch a==b en el programa anterior.

En la práctica, es inesperado, a menudo desencadena este problema, y ​​generalmente no es lo que desea.

Para ver solo la dirección de destino, use watch -location itrap_t_beg[1][222]. (Esto está disponible a partir de GDB 7.3, lanzado en julio de 2011, si todavía está en 7.1, use print &itrap_t_beg[1][222] y watch *(itrap_t)0x12345678, o la dirección que imprima)