MC, 22:50 czwartek, 31.05.2012 r.
Ilustracja do artykułu: GDB - Definiowanie nowych poleceń złożonych z już istniejących

GDB - Definiowanie nowych poleceń złożonych z już istniejących

Dziś artykuł na temat dostosowywania debuggera GDB do własnych potrzeb. Spróbujemy zdefiniować nowe polecenie opierające się na kilku istniejących, co w pewnych warunkach powinno ułatwić i znacznie przyśpieszyć proces pracy nad odrobaczaniem kodu.

Po co tworzyć złożone polecenia?

Definiowanie własnych poleceń, które będą tak naprawdę sekwencją już istniejących, tyle że zgrupowanych w pewien kompleks noszący nową nazwę, może mieć szereg zastosowań. Tutaj akurat posłużymy się prostym przykładem, w którym będziemy mieli ustawiony punkt wstrzymania (break point) wewnątrz jakiejś pętli. Wyobraźmy sobie, że zadaniem tej pętli jest rekurencyjnie zmieniać wartości pewnych zmiennych. Załóżmy również, że obliczenia przeprowadzane na tych zmiennych nie przebiegają poprawnie i chcemy prześledzić jak ich wartości zmieniają się wraz kolejnymi wykonaniami pętli. Schemat procesu debugowania może wyglądać następująco:
  • Debugger zatrzymuje się w pętli (break point)
  • Wyświetlamy wartość pierwszej zmiennej
  • Wyświetlamy wartość drugiej zmiennej
  • Wyświetlamy wartość trzeciej zmiennej
  • Kontynuujemy działanie programu (przeskakujemy do punktu pierwszego schematu)
Sytuacja taka odpowiadała by kolejno wydawanym poleceniom w GDB:
# debugger się zatrzymuje
print zmienna1
print zmienna2
print zmienna3
continue
# debugger znowu się zatrzymuje...
Gdyby chociaż w GDB istniał jakiś separator poleceń, dzięki któremu moglibyśmy wszystko zapisać w jednej linijce, oddzielając poszczególne komendy na przykład średnikiem. Byłoby to o tyle wygodne, że moglibyśmy tylko odtwarzać to polecenie wywołując je z historii (z klawiatury: strzała w górę). Niestety separator nie istnieje, dlatego właśnie wygodnie będzie zdefiniować nowe polecenie!

Jak definiować nowe, złożone polecenia?

Definiowanie nowych poleceń jest niezwykle proste. Wystarczy w konsoli DBG wpisać polecenia na kształt:
define <nazwa nowego polecenia>
<kolejne polecenia>
end
Jak widać składnia jest bardzo prosta. Zdefiniujmy zatem nowe polecenie o nazwie nextOne, które będzie zawierało komendy z naszego przykładu:
define nextOne
print zmienna1
print zmienna2
print zmienna3
continue
end
Po wykonaniu operacji definiowania, możemy korzystać z nowego polecenia - nextOne, które wykona wyświetlenie wartości interesujących nas zmiennych.

Jak zdefiniować polecenie na stałe?

Powyższa metoda dobra jest do doraźnego odrobaczania, ponieważ zdefiniowane polecenie przestanie być dostępne po ponownym uruchomieniu DBG. Jeżeli jednak chcemy zdefiniować komendę, dostępną przy każdym uruchomieniu debuggera, to musimy umieścić ją w pliku ~/.gdbinit (plik .gdbinit znajdujący się w katalogu głównym użytkownika). Zawartość tego pliku zostanie wykonana przy każdym włączeniu programu DGB. Jeśli ten plik nie istnieje w naszym systemie, to bez przeszkód możemy go utworzyć. Definicja komendy zapisana w tym pliku powinna wyglądać dokładnie tak samo jak miało to miejsce przy wpisywaniu jej do programu. Zadbajmy jedynie o czytelność tego pliku w postaci odpowiedniej tabulacji. Treść pliku .gdbinit może wyglądać następująco:
define nextOne
print zmienna1
print zmienna2
print zmienna3
end

echo "Zdefiniowano nowe polecenie - nextOne!"
Dopisaliśmy jeszcze tylko komunikat o zdefiniowaniu nowego polecenia. Od teraz przy każdym włączeniu programu GDB będziemy mieli dostępne polecenie nextOne co obwieści nam wiadomość startowa.

Komentarze (0) - Nikt jeszcze nie komentował - bądź pierwszy!

Imię:
Treść: