gdb zatrzymuje się ze zbyt dużą liczbą punktów obserwacyjnych, gdy jest tylko jeden

Question

Czy znasz inne powody, dla których nie można wstawić punktu obserwacyjnego poza zbyt wieloma punktami przerwania/punktów kontrolnych?

Mam następujący sesji debugowania:

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 

Jak widać, jest tylko jeden watchpoint jeszcze nie można wstawić przerwania.

Czy wiesz, jak mogę to naprawić?

Answer 1

O ile wiem, towar x86 Procesory mają cztery debug registers dostępne dla obsługi przerw sprzętowych/zegarków. Ogranicza to rozmiar obiektu, który można oglądać. Dopasowanie obiektu również tutaj.

Spróbuj ograniczyć zakres obserwacji do mniejszego obiektu, np. Pary pierwszych i ostatnich elementów struktury.

Answer 2

można zmusić punktów przerwań programowych (które nie mają limitu rozmiaru), uruchamiając

zestaw can-use-HW-watchpoints 0

Answer 3

Strzał odpowiedź: Stosować watch -location itrap_t_beg[1][222] lub krótka forma watch -l.

Długa odpowiedź: Quoting the GDB manual:

Oglądając złożonych wyrażeń, które odwołują się wiele zmiennych może wyczerpać zasoby dostępne dla sprzętowo wspomaga watchpoints. Dzieje się tak dlatego, że gdb musi oglądać każdą zmienną w wyrażeniu z osobno przydzielonymi zasobami.

gdb dość dosłownie obserwuje to wyrażenie, a nie jakikolwiek adres, na który wskazuje. W tym przypadku oznacza to, że punkt przerwania uderzy, jeśli sama zmiana zostanie zmieniona tak, aby ; nie jest to tylko punkt obserwacyjny dla itrap_t_beg[1][222], ale także dla samego itrap_t_beg. To może być coś więcej niż to, co jest dostępne.

W twoim przypadku itrap_t_beg ma 7 watów, 28 bajtów. Punkt kontrolny x86_64 ma do ośmiu bajtów, więc GDB potrzebuje czterech punktów obserwacyjnych dla całej struktury - plus jedna piąta dla samej siebie itrap_t_beg. Rodzina x86 obsługuje tylko cztery równoczesne punkty obserwacyjne.

Bardziej wszechstronny przykład jak watchpoints praca:

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

W teorii jest to przydatna funkcja; możesz oglądać złożoną ekspresję, łamiąc ją, gdy tylko będzie fałszywa, w pewnym sensie jak stale sprawdzane twierdzenie. Na przykład możesz watch a==b w powyższym programie.

W praktyce jest to nieoczekiwane, często powoduje ten problem i zazwyczaj nie jest to, co chcesz.

Aby oglądać tylko adres docelowy, należy użyć watch -location itrap_t_beg[1][222]. (Jest dostępny od wersji GDB 7.3, wydanej w lipcu 2011 r., Jeśli nadal korzystasz z wersji 7.1, użyj print &itrap_t_beg[1][222] i watch *(itrap_t)0x12345678 lub dowolnego adresu, który zostanie wydrukowany.)