Chciałbym jakoś „obejrzeć” zmienną (lub adres pamięci) w jądrze Linuksa (dokładniej moduł / sterownik jądra); i dowiedz się, co się zmieniło - w zasadzie wydrukuj ślad stosu, gdy zmienna się zmieniła.

Na przykład w module jądratestjiffy-hr.c wymienione na końcuta odpowiedź, Chciałbym wydrukować ślad stosu za każdym razemruncount zmienne zmiany; miejmy nadzieję, że ślad stosu będzie zawierał wzmiankę otestjiffy_timer_function, która jest rzeczywiście funkcją, która zmienia tę zmienną.

Teraz wiem, że mogę użyćkgdb aby połączyć się z debugującym jądrem Linuksa działającym powiedzmy na maszynie wirtualnej, a nawet ustawić punkty przerwania (więc miejmy nadzieję, również punkty obserwacyjne) w ten sposób - ale problem polega na tym, że faktycznie chcę debugować sterownik ALSA, w szczególności odtwarzaniedma_area bufor (gdzie otrzymuję nieoczekiwane dane) - który jest bardzo wrażliwy na synchronizację; i samo uruchomienie jądra debugowania zepsułoby czasy (nie mówiąc o uruchomieniu go na maszynie wirtualnej).

Jeszcze większym problemem jest tutaj odtwarzaniedma_area wskaźnik istnieje tylko podczas operacji odtwarzania (lub innymi słowy, między_start i_stop handlerów) - musiałbym więc nagraćdma_area adres na każdym_start wywołanie zwrotne, a następnie jakoś „zaplanuj” jego „oglądanie” podczas operacji odtwarzania.

Miałem więc nadzieję, że istnieje sposób na zrobienie czegoś takiego bezpośrednio w kodzie sterownika - tak jak w, dodaj trochę kodu w tym_start wywołanie zwrotne, które rejestrujedma_area wskaźnik i używaj go jako argumentu polecenia, które inicjuje „obserwację” zmiany; ze śladem stosu wydrukowanym z odpowiedniej funkcji wywołania zwrotnego. (Zdaję sobie sprawę, że to również wpłynęłoby na czas, ale miałem nadzieję, że będzie to wystarczająco „lekkie”, aby nie wpływać zbytnio na działanie sterownika „na żywo”).

Więc moje pytanie brzmi: czy istnieje taka technika debugowania w jądrze Linuksa?

Jeśli nie: czy można skonfigurować przerwanie sprzętowe (lub programowe), które reaguje na zmianę określonego adresu pamięci? Czy mógłbym wtedy skonfigurować taki program obsługi przerwań, który mógłby wydrukować ślad stosu? (chociaż myślę, że cały kontekst zmienia się, gdy uruchamiane są procedury obsługi IRQ, więc może uzyskanie śledzenia stosu byłoby błędne)?

Jeśli nie: czy pozostały jakieś inne techniki, które pozwoliłyby mi wydrukować ślad stosu procesu, który zmienił wartość zapisaną w danej lokalizacji pamięci jądra (miejmy nadzieję, że w żywym, nie debugującym jądrze)?