Wprowadzenie do Arm DDT
DDT to debugger, umożliwiający wykrywanie błędów, przerywanie działania programu, wykonywanie kodu krok po kroku, podglądanie wartości zmiennych, stosu wywołań funkcji itp., dostosowany do pracy z aplikacjami rozproszonymi i wielowątkowymi.
Niniejsze wprowadzenie zakłada znajomość: Tryb graficzny (przypomnienie).
Kiedy używać DDT (wskazówki)?
- jeśli w trakcie wykonania, program przerywa swoje działanie i kończy się niespodziewanym błędem
- jeśli program się zawiesza
- jeśli otrzymujemy niepoprawne wyniki i chcemy poznać przyczynę
- jeśli chcemy prześledzić działanie kodu
Korzystanie z debuggera ma największy sens gdy posiadamy dostęp do kodu źródłowego.
Jak uruchomić DDT?
Rozważmy przykładową aplikację, uruchamianą pod MPI:
mpiexec -n 4 ./mmult1_c.exe 1024 |
W celu jej zdebugowania wystarczy (pracując w trybie graficznym):
- załadować pakiet arm-forge
module add plgrid/tools/arm-forge |
- skompilować program z flagą -g (symbole do debugu);
bez tej opcji debuger nie będzie wiedział która linia jest wykonywana, być może będą znane nazwy funkcji - zaleca się kompilację bez optymalizacji, tj. z flagą -O0;
przy włączonych optymalizacjach (-O2/-O3), informacje z debugera mogą być zaburzone - uruchomić program w ten sam sposób, dodając na początku komendy "ddt"
ddt mpiexec -n 4 ./mmult1_c.exe 1024 |
W okienku, które się pojawi, klikamy RUN.
Otworzy się wtedy właściwe GUI programu DDT, w którym będziemy wykonywać proces debugowania.
Podstawowe funkcjonalności
- stack trace - wielowątkowy (gdzie się znajduje który proces/wątek)
- możliwość tworzenia grup procesów (pasek na górze)
- breakpointy
- watchpointy
- ewaluacja wyrażeń
- widok "LOGu" (zapis pracy debuggera)
- input i output programu
- podgląd wartości w danej linijce / podgląd zmiennych lokalnych (zestawienie z wszystkich procesów)
- kontrola wykonania programu (start, stop, step, step into, restart, ...)
Dodatkowe uwagi
- User Guide (wersja 20.2),
- DDT z opcją offline, umożliwia wykonanie kodu pod kontrolą debuggera, bez interakcji użytkownika; może to mieć zastosowanie gdy chcemy wykonać kod i podglądnąć wartości w konkretnym miejscu, albo gdy aplikacja kończy się błędem tylko raz na jakiś czas (wtedy spośród wielu wykonań, to które zakończy się błędem dostarczy nam informacji o błędzie); wartości zapisane w raporcie, odpowiadają temu co pojawia się w "Logbook"
ddt --offline=debug-report.html --break-at=<file>:<line> (...command...) |
- opcja attach, umożliwia podpięcie się do już uruchomionego procesu (podając jego PID); bardzo wygodnie można to zrobić z poziomu GUI programu
- w DDT można otwierać pliki core-dump