Jak funguje debugger. Ladění programu Podívejte se, co je "Ladění programu" v jiných slovnících

[z metod]

Definice 9.20 Debugger je softwarový modul, který umožňuje provádět základní úkoly související se sledováním provádění výsledného aplikačního programu.

Definice 9.21 Ladění je monitorování procesu provádění výsledného aplikačního programu.

Ladění zahrnuje následující hlavní funkce:

Sekvenční krok za krokem provádění výsledného aplikačního programu na základě kroků strojových příkazů nebo operátorů vstupního jazyka;

Spouštět výsledný program, dokud nedosáhne jednoho z daných bodů přerušení (bodů přerušení);

Provádění výsledného programu, dokud nenastanou určité specifikované podmínky spojené s daty a adresami zpracovávanými tímto programem;

Zobrazení obsahu paměťových oblastí obsazených příkazy nebo daty výsledného programu.

Původně byly debuggery samostatné softwarové moduly, které dokázaly zpracovat výsledný program z hlediska strojového příkazového jazyka. Jejich možnosti byly omezeny především na modelování provádění výsledných programů v architektuře odpovídajícího počítačového systému. Provádění může probíhat nepřetržitě nebo v krocích.

Další vývoj debuggerů je spojen s následujícími základními body:

Vznik integrovaných vývojových prostředí;

Vznik hardwarové podpory pro ladicí nástroje v mnoha počítačových systémech.

První z těchto kroků umožnil vývojářům programů pracovat nikoli z hlediska strojových instrukcí, ale z hlediska zdrojového programovacího jazyka, což výrazně snížilo mzdové náklady při ladění softwaru. Současně přestaly být debuggery samostatnými moduly a staly se integrovanou součástí programovacích systémů, protože nyní musely podporovat práci s tabulkami identifikátorů a plnit inverzní úlohu identifikace lexikálních jednotek jazyka. To je způsobeno skutečností, že v takovém prostředí dochází k ladění programu z hlediska názvů zadaných uživatelem, nikoli z hlediska interních názvů přidělených kompilátorem. Odpovídající změny byly vyžadovány také ve funkcích kompilátorů a linkerů, protože musely obsahovat tabulku jmen v objektu a spustitelné soubory pro zpracování ladicím programem.

Druhý krok nám umožnil výrazně rozšířit možnosti ladicích nástrojů. Nyní nepotřebovali modelovat provoz a architekturu odpovídajícího počítačového systému. Spuštění výsledného programu v režimu ladění bylo možné v

stejné prostředí jako v normálním režimu. Úkol debuggeru zahrnoval pouze funkce převedení počítačového systému do příslušného režimu před spuštěním výsledného programu pro ladění.

V mnoha ohledech jsou tyto funkce prioritou, protože často vyžadují instalaci systémových tabulek a příznaků procesoru počítačového systému.

Debuggery v moderních programovacích systémech jsou moduly s vyvinutým uživatelským rozhraním, které přímo pracují s textem a moduly zdrojového programu.

Mnoho jejich funkcí je integrováno s funkcemi editorů zdrojového textu obsažených v programovacích systémech.

Ladicí program nebo debugger je modul vývojového prostředí nebo samostatná aplikace určená k vyhledávání chyb v programu. Ladicí program vám umožňuje provádět krok za krokem trasování, monitorovat, nastavovat nebo měnit hodnoty proměnných během provádění programu, nastavovat a odstraňovat body přerušení nebo podmínky zastavení atd.

Seznam debuggerů

AQtime je komerční debugger pro aplikace vytvořené pro .NET Framework verze 1.0, 1.1, 2.0, 3.0, 3.5 (včetně aplikací ASP.NET) a také pro Windows 32- a 64bitové aplikace.

DTrace je dynamický sledovací rámec pro Solaris, OpenSolaris, FreeBSD, Mac OS X a QNX.

Electric Fence je debugger paměti.

GNU Debugger je programový debugger z projektu GNU.

IDA je výkonný disassembler a nízkoúrovňový debugger pro operační systémy Windows a GNU/Linux.

Microsoft Visual Studio je prostředí pro vývoj softwaru, které obsahuje nástroje pro ladění od společnosti Microsoft.

OllyDbg je bezplatný nízkoúrovňový debugger pro operační systémy Windows.

SoftICE je nízkoúrovňový debugger pro operační systémy Windows.

Sun Studio je prostředí pro vývoj softwaru, které obsahuje ladicí program dbx pro operační systémy Solaris a GNU/Linux od Sun Microsystems Corporation.

Dr. Watson je standardní ladicí program Windows, který umožňuje vytvářet výpisy paměti.

TotalView je jedním z komerčních debuggerů pro UNIX.

WinDbg je bezplatný debugger od společnosti Microsoft.

Takže kódujete, kódujete, ladíte,
ladění... Stop! Přemýšleli jste někdy o tom, jak
funguje debugger? Ne? Pak poslouchej...
Začněme tím, že celá rodina debuggerů
rozdělena na ladicí programy aplikací a
ladicí programy jádra. Rozdíl je v jejich provedení,
zpravidla je to tak
ladicí programy aplikací používají rozhraní API pro ladění OS
(funkce, struktury) a ladicí programy jádra -
možnosti přímého ladění
procesor (registry, příkazy). Očividně,
že ladicí programy aplikací se snáze používají
implementací, tak začneme s nimi.

Ladicí programy aplikací

Popíšu Windows Debugging API. Tak pro
Aby bylo možné zahájit ladění, vlákno debuggeru
by měl začít proces ladění takto,
aby OS věděl, že ten, který se spouští
proces bude v ladění. Pro
k tomu musíte spustit ladicí program
program s funkcí CreateProcess s parametrem
dwCreationFlag se rovná DEBUG_ONLY_THIS_PROCESS (nebo DEBUG_PROCESS,
pokud debugger může ladit více
procesy současně). Nyní debugger
musí vstoupit do tzv ladicí cyklus. Pro tohle
musíte vstoupit do smyčky voláním funkce WaitForDebugEvent
(while(WaitForDebugEvent(...)==1)) a po dokončení
zpracování jakékoli události ladění
zavolejte ContinueDebugEvent. Takže zobecněné schéma
Debugger funguje:

CreateProcess("cesta_k_ladi_programu",...,LADI_JEN_TENTO_PROCES,...);
while(WaitForDebugEvent(...)==PRAVDA)
{
process_events (viz níže)
...
...
...

ContinueDebugEvent(...);
}

Ano, mimochodem, výše jsem řekl STREAM-debugger -
je důležité (doporučení Microsoftu:), aby smyčka
bylo ladění popsané výše
samostatné vlákno debuggeru. Jinak debugger
bude viset při čekání na události
ladění Ale to je důležité pro vážné
debuggery, ale zatím to nemůžete udělat
obtěžovat (to je pro vás, pro budoucnost).
Nyní se musíme naučit přijímat události
ladění Ve Win DAPI na to existuje struktura
DEBUG_EVENT (podívejte se na SDK, nebudu to popisovat, protože...
struktura není malá). Ukazatel na toto
struktura je předána jako první parametr
funkce WaitForDebugEvent a ta zase
naplňuje to pro nás něčím zajímavým
informace. Samotná událost ladění, která
potřeba/lze zpracovat bude v prvku
DEBUG_EVENT dwDebugEventCode. Takže co tam je?
události ladění:

CREATE_PROCESS_DEBUG_EVENT – probíhá ladění
je vytvořen nový proces (nebo byl spuštěn ladicí program
Nemusíme ladit již aktivní proces)
CREATE_THREAD_DEBUG_EVENT - podle toho v
v laděném procesu se vytvoří nový proces
tok
EXCEPTION_DEBUG_EVENT – probíhá ladění
došlo k výjimce (bod přerušení,
dělení nulou atd.)
EXIT_PROCESS_DEBUG_EVENT – nastane při ukončení
proces se ladí
EXIT_THREAD_DEBUG_EVENT – nastane při ukončení
vlákno laděného procesu
LOAD_DLL_DEBUG_EVENT - dochází při načítání DLL do
adresní prostor
OUTPUT_DEBUG_STRING_EVENT – nastane, když
laděný program volá OutputDebugString
UNLOAD_DLL_DEBUG_EVENT – proces se ladí
uvolní DLL
RIP_INFO - (pouze Win98), zpráva o
chybná situace (například uzavření
neplatné deskriptory, tzn. chyby, ne
stejně smrtící jako u EXCEPTION_DEBUG_EVENT)

Když nastanou události ladění
existuje mnoho nuancí, které nejsou popsány
mě. Například CREATE_PROCESS_DEBUG_EVENT a
CREATE_THREAD_DEBUG_EVENT nastane PŘED
proces nebo vlákno se spustí.
Přečtěte si více v MSDN, protože... dnes my
Pojďme vytvořit VELMI jednoduchý debugger.

No, něco jsme si vyjasnili, teď něco napíšeme
jako debugger:

To je vše. Zkompilujte, spusťte. myslím, že ty
uhodl to jako parametr pro toto
Ladicí program by měl dostat cestu
laděný program. Teď víš
nejprimitivnější základy debuggeru
aplikace pro Win. Napsáno jako
například debugger není ani tak debugger,
kolik programů zobrazuje události
ladění Chcete-li vytvořit skutečný debugger
vyžaduje to hodně píle a touhy. Li
zajímá vás toto téma, přečtěte si co
napsáno o ladění v MSDN a jít!

Ladicí programy jádra

Hladce se blížící ladicí programy jádra... Oooooh!
Je to velmi zajímavé a stejně těžké.
Jak jsem již řekl, ladicí programy jádra
využívat prostředky procesoru. řeknu hned
že se omezím na popis těchto zdrojů a
popis jejich použití. Příklad programu
nebude 🙁 V moderních procesorech Intel (a
kompatibilní s nimi), počínaje 80386 us
8 dostupných registrů ladění (DR0-DR7),
umožňuje nastavit kontrolní body na
oblasti paměti a porty pro čtení/zápis
I/O (od Pentia). A to je v pohodě
Řeknu ti to! Celkový počet kontrolních bodů
jen čtyři 🙁 Dobře, zvažme
ladicí registry DR0-DR7. Nejdůležitější
jedním z nich je DR7, protože přesně on je
řídit registr ladění, umožňující
koordinovat práci lomových bodů. Ano,
Mimochodem, všech osm registrů ladění je 32bitových.
Podívejme se blíže na registr DR7:

bity 31-30: pole LEN pro bod přerušení 3
bity 29-28: R/W pole pro t/o 3
bity 27-36: pole LEN pro t/o 2
bity 25-24: R/W pole pro t/o 2
bity 23-22: pole LEN pro t/o 1
bity 21-20: R/W pole pro t/o 1
bity 19-18: pole LEN pro t/o 0
bity 17-16: R/W pole pro t/o 0

pole LEN udává délku t/o:
00–1 bajt
01–2 bajty
10-3 bajtů
11-4 bajtů

pole R/W specifikuje podmínku pro spuštění t/o:
00 - provedení příkazu
01 - záznam dat
10 - přístup k I/O portu (pokud je 3
Bit registru CR4 je 1), jinak nedefinováno
11 - čtení/zápis

bity 15-14: 0-0 (rovná se nule)
bit 13: při nastavení jakýkoli přístup k
ladění registrů (i z kruhu 0)
vyvolá výjimku
bity 12-10: 0-0-1
bity 9-8: 1-1 (a zde je doporučení Intelu :)
bit 7: 1 - povolit t/o 3
bit 5: 1 - povolit t/o 2
bit 3: 1 - povolit t/o 1
bit 1: 1 - povolit t/o 0
bity 8,6,4,2,0: stejné jako 7,5,3,1, ale reset
pokaždé, když změníte úkol (relevantní
pro chráněný režim, v reálném režimu
tyto dvojice registrů jsou ekvivalentní)

Registry DR0-DR3 definují lineární adresy
čtyři body zlomu (0-3).
Zde je několik poznámek: pokud je velikost t/o -
slovo, pak adresa musí být sudá,
pokud je dvojslovo, pak adresa musí být
násobek čtyř.
Nakonec registr DR6 zobrazí stav
ladění:

bity 31-16: nastavte vše na jedničku
bit 15: je-li 1, je vyvolána výjimka
přepínací úlohy (opět relevantní
pro chráněný režim)
bit 14: nastaven při trasování
bit 13: nastavte jako další
příkaz přistupuje k jakémukoli ladění
registru (bit 13 registru DR7 musí být
nainstalováno)
bit 12:0
bity 11-4: jedničky
bit 3: t/o 3 spuštěn
bit 2: t/o 2 spuštěno
bit 1: t/o 1 spuštěn
bit 0: t/o 0 spuštěno

Ox-x-x, toto není Windows Debugging API :)

;Tento příklad nefunguje ve Win (a ani v okně DOS)
mov eax, 000000001100000110000010; délka t/o je 1 bajt,
nastavit na čtení/zápis do paměti
mov ebx, 90000h ;adresa bodu přerušení (kdo bude číst/spouštět
napište - okamžitě to zaprská)
mov dr7, eax
mov dr0, ebx

Ladicí programy po instalaci čekají
generování int 0x1 při přístupu k t/o a příjmu
management vytváří chaos 🙂 S porty všechno
přesně to samé, ale musíte jej nejprve nainstalovat
jeden 3. bit registru CR4 a nastavte adresu
port do jednoho z registrů DR0-DR3.

Ze starých možností ladění můžete
mluvit o zlomových bodech a
trasování. Kontrolní bod zlomu
implementováno pomocí operačního kódu 0xCC. Po setkání
procesor zavolá int 0x3 a uloží jej
registr příznaků zásobníku, registr CS, registr IP,
zakazuje přerušení (příznak FI v registru
flags nastaven na 0), resetuje příznak
stopy. Po tomto znovu debugger
může si s programem dělat, co chce. A
o trasování. Je organizován instalací
TF příznak (trace flag) na jedničku.
Nastavte TF na jedničku a procesor poté
každý příkaz se bude nazývat int 0x1,
uložení registru příznaků a registru IP do zásobníku
a vymazání příznaku TF. Záludný debugger
chytil výjimku a - opět chaos
🙂 Pro ladění v reálném režimu procesoru
ladicí program měl zachytit
přerušení (výjimky) 0x1 a 0x3 a
zpracovat je podle vlastního uvážení. V
v chráněném režimu je vše v podstatě stejné (in
smysl, musíte také zachytit 0x1 a 0x3), ale
zde, když dojde k výjimce
je uvedeno více informací, ale
program v chráněném režimu
Je to dost těžké. A to už v nultém kroužku
Ochrana Windows a ještě více. Málem bych zapomněl říct
o tzv emulující debuggery. Tyto
debuggery emulují provádění příkazů
procesor laděného programu (dobře,
Procesní registry jsou samozřejmě emulovány). Od věci
pokud jde o ochranu proti kódu proti ladění, toto
skvělá pomoc. Ale také pro emulaci
Vždy budou existovat debuggery.

K čemu jsi přišel?..

No, teď víte, alespoň přibližně,
jak fungují debuggery. Ano, mimochodem, SoftIce -
ladicí program jádra a také jediný z nich,
schopný ladit pomocí jednoho počítače.
"Co tím myslíš jeden počítač?" - ptáš se. A
to znamená, že zbytek je znám
Ladicí programy jádra provádějí ladění „přes modem“,
těch. systém se ladí spolu s jádrem
debugger na jednom počítači a ovládání
jádro se vyskytuje přes síť na jiném počítači. Tady
aby. A zpravidla zabudované do nástrojů
vývojové debuggery nejsou nic jiného než
ladicí programy aplikací, a ne ty nejlepší
nejlepší. Co použít, ptáte se mě.
Ano, znáte to sami - SoftIce :) A taky docela dobrý
debugger - WinDBG. Dodává se s PlatformSDK. Hodně štěstí
v chytání brouků!

Uvažujme proces ladění programu, který řeší rovnici ve tvaru AX+B=0 bez uložení dat do souboru (prohlášení problému viz kapitola 3). Budeme předpokládat, že formulář obsahuje pouze prvky umístěné na záložce „Data“ (obr. 3.5) a má tvar (obr. 8.6). Názvy textových oken pro zadávání koeficientů TBA a TBB a také název štítku pro zobrazení kořene LBX jsou umístěny uvnitř grafických obrázků zadaných objektů. Názvy CB1, CB2 a CB3 jsou přiřazeny příkazovým tlačítkům. Názvy dat A, B, X pro koeficienty a, b a kořen X. Vstupní a výstupní data

Rýže. 8.7. P-graf programu

Struktura programu

Rýže. 8.8. Struktura programu

S tímto programovým kódem testování rozhraní. Program by měl reagovat na kliknutí na tlačítka zobrazením příslušných zpráv, kliknutím na objekty Text Box by se měl kurzor umístit dovnitř objektů, zadáním znaku by se měl změnit obsah aktivního objektu Text Box. Mapa testování rozhraní je uvedena v tabulce. 8.2.

Tabulka 8.2

Testovací mapa rozhraní

Testování programu na úrovni procedur a funkcí programátora probíhá při psaní kódu procedur a funkcí. Pro takové testování můžete vytvořit speciální formulář pro ladění s tlačítky pro volání procedur a udělat z něj počáteční formulář. V tomto případě taková potřeba není, protože základní forma je pro tento účel docela vhodná.

První sada dat zahájí provádění příkazu S=str(-b/a), druhý – operátor S="Nedefinovaný kořen", třetí – operátor S="Root neexistuje". V prvním případě je hodnota kořene (– 3). Vypočtené hodnoty koeficientů a kořene lze sledovat na formuláři v textových oknech a na štítku LBX.

Testování dokončeného programového kódu se provádí v souladu s mapou testování programu (tabulka 8.3).

Tabulka 8.3

Testovací mapa programu

Dále z textu procedur a funkcí odstraníme příkazy zobrazené normálním písmem a znovu otestujeme program v souladu s mapou testování programu. Výsledky by měly být identické, ale neměly by existovat žádné ladicí zprávy.

8.2. Vytvoření instalační sady
softwarový nástroj

Po dokončení práce na ladění softwaru je docela snadné získat jeho spustitelný kód. Může být sestaven ve dvou formách: jako nezávislý spustitelný kód a jako P-cod (pseudokód), který ke spuštění programu vyžaduje soubor obsažený ve Visual Basicu. První kód je delší, ale může fungovat bez jakýchkoli dodatků systému Visual Basic, druhý kód je kratší, ale vyžaduje přítomnost zadaného souboru. Obvykle je preferována první možnost. Způsob kompilace je specifikován v okně "Project Properties".

Pro sestavení instalační sady (distribuce) se spustí speciální aplikace (Application SetupWizard pro Visual Basic 5 a Package and Deployment Wizard pro Visual Basic 6). Proces vytváření distribuce probíhá interaktivně v několika krocích. Celkový pohled na okna aplikace Průvodce nastavením aplikace je na Obr. 8.12.

A) b) Obr. 8.12. Okna Průvodce nastavením aplikace "Výběr a konfigurace projektu" (a) a "Metoda distribuce" (b)

První okno Průvodce nastavením aplikace zobrazuje různé zprávy, zejména o účelu programu a hlavních akcích, které provádí. Toto okno zde není zobrazeno. Dalším krokem je výběr projektu pro vytvoření instalační sady a konfigurace aplikace. K tomuto účelu slouží okno „Výběr a nastavení projektu“ (obr. 8.12a). Toto okno nastavuje cestu k souboru projektu a možnosti, které vám umožní otevřít instalační program s nebo bez vytvoření závislého souboru, vytvořit distribuční sadu pro internetovou distribuci a jednoduše vytvořit závislý soubor. V dalším okně "Způsob distribuce" (obr. 8.12, b) zvolíte způsob umístění sady na médium: na jednu disketu, do jednoho adresáře na pevném disku pro kopírování na CD-Rom, nebo do více adresářů s názvy Disk1, Disk2, ... pro vytvoření sady disket.

A) b) Obr. 8.13. Okna Průvodce nastavením aplikace "Cílový adresář" (a) a "Výsledný soubor" (b)

V dalším okně vyberete cílový adresář, který bude obsahovat vytvářenou instalační sadu. Toto okno určuje disk a cestu k souborům instalační sady. Strom složek umožňuje vybrat požadovanou cestu k zadaným souborům. Další okno průvodce specifikuje server a místní komponenty ActiveX. Toto okno není na obrázku znázorněno. Předposlední okno aplikace „Final File“ (obr. 8.13b) zobrazuje soubory připojené k souborům projektu. Zpravidla se jedná o knihovny *.dll. Průvodce nastavením aplikace automaticky vygeneruje seznam souborů, které je třeba přidat do sady. Je možné přidávat vlastní soubory, kromě těch, které aplikace přidává automaticky. Poslední dvě okna zobrazují zprávy indikující, že sada byla sestavena a aplikace dokončena. Tato okna

jsou nevýrazné a nejsou uvedeny v návodu.

Ladicí program je druhá věc po kompilátoru potřebném k vytváření programů. Mnoho z těch, kdo píší počítačové programy a používají debugger, si však neuvědomují principy a mechanismy jeho fungování.

Je těžké být debuggerem...

Vzhledem k tomu, že programátoři používají debugger ve dne i v noci, zvláště když vstoupí do režimu hlubokého ladění, stojí za to říci, že pokud by debugger nebyl program, ale kus hardwaru, pravděpodobně by se přehříval a rozbil. Protože ani kompilátor nemá tolik práce, kolik dostane debugger.

Samozřejmě, protože nyní existuje mnoho různých programovacích jazyků, pro každý z nich existují různé debuggery. A samozřejmě pro různé kategorie těchto jazyků existují rozdíly v práci debuggerů: například debugger pro programy v interpretovaném Ruby bude fungovat jinak než pro jazyk Java zkompilovaný do bajtového kódu a debugger pro Java v turn, bude mít rozdíly od ladicího programu Visual C++.

Budu mluvit o ladění pro platformu Windows. Po pochopení principů fungování debuggerů pro něj bude možné porozumět jak debuggerům pro systémy POSIX, tak debuggerům, které nepracují na úrovni operačního systému, ale na úrovni virtuálního stroje nebo nějakého interpreta.

Debuggery pro Windows: dva typy

Existují dva zásadně odlišné typy ladicích programů pro Windows. Myslím, že na první narazil každý při programování v Delphi (neprogramoval se v něm? Těžko uvěřit. V čem jsi programoval ve škole a na střední škole?). Jedná se o vlastní ladicí programy aplikací. Je jich mnoho a existují jak jednotlivě, tak (mimochodem zvláště často) jako součást integrovaných prostředí pro vývoj aplikací. Mezi debuggery distribuovanými jako samostatné softwarové produkty je tradičně vyzdvihován OllyDbg a kdysi jsem o něm psal v Computer News.

Druhým typem debuggeru je ladicí program jádra operačního systému. Nacházejí se a používají méně často a jejich design se výrazně liší od vlastních ladicích programů. Nejznámějším a zároveň nejlepším debuggerem jádra je SoftIce. Možná jste o něm nejen slyšeli, ale dokonce ho používali.

Protože práce každého ze dvou typů debuggerů má svá specifika, budu o každém z nich mluvit podrobněji.

Vlastní aplikace Debugger

Ladicí program pro uživatelské aplikace je jednodušší, protože operační systém přebírá tu nejpodřadnější a nejšpinavější práci. Windows má speciální softwarová rozhraní, která jsou navržena pro ladění aplikací na uživatelské úrovni – nazývají se Windows Debugging API. Jsou to ladicí rozhraní API, která používají všechny ladicí programy, které jsou zabudovány do oblíbených integrovaných vývojových prostředí pro Windows.

Aby mohlo začít ladění, musí debugger spustit laděný proces speciálním způsobem - aby systém věděl, že tento proces bude v ladění. Poté začíná cyklus ladění: program je prováděn, dokud nenastane určitá událost, která se nazývá událost ladění. Tím se spustí smyčka ladění v samostatném vláknu, aby se zabránilo zablokování ladicího programu.

Ale to je jen začátek. Protože zábava s debuggerem začíná, když dojde k události ladění. Ostatně, co je úkolem debuggeru? Pomoci programátorovi lokalizovat chybu s přesností na konkrétní funkci, konkrétní operaci, konkrétní proměnnou. S tímto obtížným úkolem může debuggeru pomoci i operační systém.

Takže došlo k události ladění a pak musíme nějak zjistit, jak to souvisí s textem programu. To je možné pouze v případě, že samotný program obsahuje speciální ladicí informace – tabulku ladicích symbolů. Obsahuje informace o shodě mezi adresami a názvy funkcí, datové typy a čísla řádků kódu. Právě díky nim je možné ladění, které zná každý programátor Windows. Tabulky symbolů mají různé formáty, a proto není vždy možné ladit program zkompilovaný jedním vývojářským kompilátorem pomocí debuggeru jiného výrobce. Nejběžnější formát však stále lze specifikovat - jedná se o PDB (Program Database), který vyvinula přirozeně společnost Microsoft Corporation.

Pokud je tedy tabulka symbolů ladění ve formátu PDB, můžete použít speciální nástroj od společnosti Microsoft - symbolický ladicí procesor. Kdysi byl součástí jádra systému a jmenoval se Imagehlp.dll, ale už dávno byl oddělen do samostatné knihovny. Znakový procesor umožňuje najít nejbližší otevřenou funkci nebo globální proměnnou na dané adrese a také číslo řádku a název zdrojového souboru, ve kterém se tento řádek nachází. Podporovány jsou i inverzní operace, například hledání adresy funkce podle jejího názvu.

To samozřejmě není všechna práce, kterou ladicí program vlastní aplikace dělá. Například při ladění vícevláknových aplikací vzniká mnoho velmi jemných problémů souvisejících s interakcí vláken. I při ladění tak relativně jednoduchých věcí, jako jsou služby, existují určité nuance.

Ale nebudeme se nyní zabývat nuancemi - na konci článku vám řeknu, kde si o nich můžete přečíst. Nyní se podíváme na ladicí programy jádra.

Debugger jádra

Ladicí programy jádra jsou mnohem složitější programy než debuggery uživatelských aplikací a myslím, že je zcela jasné proč: nemají asistenta operačního systému. V tomto případě je jejich klientkou, protože je to ona, kdo nakonec musí ladit.

Většina ladicích programů jádra vyžaduje ke své činnosti dva počítače spojené kabelem nulového modemu. Nulový modem je způsob, jak propojit dva počítače přímo kabelem přes jejich porty COM nebo LTP. Druhý počítač je potřeba, protože část debuggeru sedící na prvním (na tom, kde je nainstalován laděný systém) má omezený přístup k hardwaru, a proto všechna data jdou přes nulový modem do druhého počítače.

Moderní procesory architektury Intel x86 mají speciální ladicí registry (staré 368 i novější modely procesorů jich mají pouze osm, nazývají se DR0-DR7). Tyto registry umožňují ladicímu programu nastavit body přerušení při čtení a zápisu paměti a také na I/O portech. Obecně vše vypadá přesně takto a myslím, že nemá cenu nyní podrobně popisovat, za co je každý z registrů ladění zodpovědný, co přerušuje implementovat body přerušení a poskytovat další podobné informace. Je lepší vám říci o konkrétních existujících ladicích programech jádra pro Windows.

No, za prvé, je to debugger zabudovaný do samotného jádra operačního systému. Je přítomen ve všech operačních systémech řady NT, počínaje Windows 2000. Je součástí souboru NTOSKRNL.EXE a lze jej aktivovat nastavením možnosti "/Debug" pro operační systém v souboru BOOT.INI. Tento debugger vyžaduje připojení nulovým modemem a druhý počítač se stejným OS.

Existuje další ladicí program jádra od společnosti Microsoft - WinDBG. Přísně vzato se nejedná o ladicí program jádra, ale o hybridní debugger, který lze také použít k ladění aplikací na uživatelské úrovni. Na rozdíl od debuggeru zabudovaného v jádře má grafický shell, a proto se snáze používá. Tento debugger také podporuje speciální rozšíření, která mohou být užitečná pro některé úlohy ladění. Ale také to vyžaduje dva počítače k ​​ladění jádra.

Existuje však ladicí program jádra, který dokáže ladit na jednom počítači. Tohle je SoftIce. SoftIce zároveň umí ladit i aplikační programy. Použití tohoto debuggeru pro uživatelské programy má své opodstatnění např. v případě ladění systémů reálného času vázaných na systémový časovač. Pokud ladíte pomocí běžného debuggeru, může být výsledek nesprávný, i když program běží správně, a SoftIce zastaví program i časovač. To je užitečné při ladění vícevláknových aplikací. SoftIce má navíc velmi, velmi dobře propracované prostředky pro zobrazení informací o všech vláknech v systému, o synchronizaci vláken pro vícevláknové aplikace, informace o handlech... Jedinou nevýhodou tohoto debuggeru je jeho složitost pro programátora aplikací. Ale z jaderných debuggerů je to nejjednodušší a nejúčinnější.

Pro ty nejzvídavější

Nyní samozřejmě není řeč o debuggerech pro aplikace Windows tak relevantní jako před deseti lety. O internet se začal zajímat celý svět a hlavními uživateli SoftIce byli crackeři, neúnavní pracovníci v oblasti pirátství. Není to však tak špatné. Komunikace se SoftIce nepochybně rozvíjí člověka, pokud jde o počítačové znalosti, i když samozřejmě, pokud komunikujete pouze s debuggery a nekomunikujete se skutečnými lidmi, některé vedlejší účinky jsou možné, myslím, že o tom už každý tuší.

Debuggery jsou některé z nejvýraznějších typů softwaru, ale z hlediska vývoje jsou i ladicí programy na uživatelské úrovni poměrně složité. Ale přesto, pokud máte chuť a čas vyvinout svůj vlastní debugger, vaše znalosti v oblasti operačních systémů a programování se výrazně zvýší, což znamená, že vaše šance na získání dobře placené práce se zvýší.

Pokud si tedy chcete vytvořit svůj vlastní debugger, měli byste si nejprve přečíst materiály na toto téma. Podle mého názoru je nejlepší knihou začít kniha Johna Robbinse Ladění aplikací pro Windows. Je již stará, vyšla v roce 2001, ale informace v ní obsažené jsou aktuální i dnes, neboť mají obecný, byť nějakým způsobem zásadní charakter. Tato kniha obsahuje příklady psaní debuggerů pro Windows a bude také užitečná, pokud programujete v C++ a chcete lépe porozumět zpracování výjimek. Ve skutečnosti jsem se z této knihy dozvěděl informace o debuggerech uvedených v článku. Pokud tuto knihu nemůžete najít (koneckonců, je už docela stará), existuje několik adres, které se vám mohou hodit. První je takto: www.xakep.ru/post/19158/default.asp. Tento článek z magazínu Hacker se zabývá trochu podrobněji o ladicích programech jádra než já a obsahuje také kód pro jednoduchý ladicí program. A na kalashnikoff.ru/Assembler/issues/016.htm se můžete naučit, jak napsat debugger DOS. Ale samozřejmě je nejlepší si přečíst MSDN a zároveň si najít nějaký open source debugger, abys tomu porozuměl. A samozřejmě, pokud jste se pustili do psaní debuggeru, pak úspěch v tomto obtížném úkolu!

Dalším modulem programovacího systému, jehož funkce úzce souvisí s prováděním programu, je debugger.

Debugger je softwarový modul, který umožňuje provádět základní úkoly související se sledováním procesu provádění výsledného aplikačního programu. Tento proces se nazývá ladění a zahrnuje následující hlavní funkce:

sekvenční postupné provádění výsledného programu na základě kroků strojových příkazů nebo operátorů vstupního jazyka;

provádění výsledného programu, dokud nedosáhne jednoho ze zadaných bodů přerušení (bodů přerušení);

provádění výsledného programu, dokud nenastanou určité specifikované podmínky spojené s daty a adresami zpracovávanými tímto programem;

prohlížení obsahu paměťových oblastí obsazených příkazy nebo daty výsledného programu.

Původně byly debuggery samostatné softwarové moduly, které dokázaly zpracovat výsledný program z hlediska strojového příkazového jazyka. Jejich možnosti byly omezeny především na modelování provádění výsledných programů v architektuře odpovídajícího počítačového systému. Provádění může probíhat nepřetržitě nebo v krocích.

Další vývoj debuggerů je spojen s následujícími základními body:

Vznik integrovaných vývojových prostředí;

Vznik hardwarové podpory pro ladicí nástroje v mnoha počítačových systémech.

První z těchto kroků umožnil vývojářům programů pracovat nikoli z hlediska strojových instrukcí, ale z hlediska zdrojového programovacího jazyka, což výrazně snížilo úsilí o ladění.

software. Současně přestaly být debuggery samostatnými moduly a staly se integrovanou součástí programovacích systémů, protože nyní musely podporovat práci s tabulkami identifikátorů a plnit inverzní úlohu identifikace lexikálních jednotek jazyka. To je způsobeno skutečností, že v takovém prostředí dochází k ladění programu z hlediska názvů zadaných uživatelem, nikoli z hlediska interních názvů přidělených kompilátorem. Odpovídající změny byly také vyžadovány ve funkcích kompilátorů a linkerů, protože musely obsahovat tabulku názvů v objektu a spustitelné soubory, aby je zpracoval ladicí program.

Druhý krok umožnil výrazně rozšířit možnosti ladicích prostředí Nyní již nevyžadovaly modelování počítače a spouštění výsledného programu v ladicím režimu bylo možné ve stejném prostředí jako v normálním režimu. Úkolem debuggeru byly funkce převodu počítačového systému na odpovídající pi h před spuštěním výsledného programu pro ladění příznaků výpočetního procesoru

Debuggery v moderních programovacích systémech jsou moduly s vyvinutým rozhraním pot, y.i.-i.. pracující přímo s textem a programové moduly m-one. Mnohé z jejich funkcí jsou integrovány s funkcemi LF< ют... редакторов исходных текстов, входящих в сое urn in. .«mi программирования.

Podívejme se na možnosti ladicího programu systému npoi rammprop.mm. Delphi. Jedná se o výkonný debugger zabudovaný do integrovaného vývojového prostředí. Sada podporována - im .\, P\ """

obsahuje vše, co byste od debuggeru očekávali: trasování a pot. A

provádění, nastavení bodů přerušení, přidávání a o, m...,. řízené hodnoty, výpočet a úprava dat I-> > .-zobrazení obsahu zásobníku.

Bodystop (zlomové body) nebo prostě ociaiumi.i, pot..,.,..-při splnění určitých podmínek pozastavíme. p,.i.,. t , programy. Nejčastěji jsou body přerušení umístěny v řádku kódu onpi d.p.pi a přerušení nastává ve stejnou dobu, účinnost, d.mt. , řádek by se měl začít vykonávat. Takovou zastávku lze provést na< ми,.п..., например, щелкнув слева от строки кода. Если ш-ш.- ..м.» < проанализировать поведение программы внутри опред.-тч...,.,

procedur nebo funkcí, stačí jednoduše nastavit 1 bod o(mi

oh první řádek.

Podmiňovací způsob tečka stop. Můžete zadat další< поим. >stop a program se pozastaví -..m dosáhne určitého řádku kódu pouze při spuštění

ModerníHumanitárníUniverzita

Modernífuj

u" mpiin. Typickým případem použití takového bodu přerušení by bylo přerušení kódu uvnitř smyčky. Pravděpodobně nebudete chtít zastavit a minispustit program pokaždé, když se smyčka spustí - což se stává stovky, možná tisícekrát. Místo neustálého spouštění programu můžete nastavit moshnov bod, když proměnná dosáhne určité hodnoty.

Tečka stop Podle léčba Na data. Tento typ bodu přerušení pozastaví provádění programu při změně konkrétního umístění v paměti. Používá se pro nízkoúrovňové o| problematické při sledování chyb při přiřazování hodnot proměnným. Můžete také zadat počáteční adresu oblasti paměti, kterou chcete ovládat, a její velikost (v bajtech) Nastavením požadované velikosti můžete ovládat proměnnou libovolného typu: char (1 byte) a Integer (4 bajty). do pole nebo záznamu libovolné velikosti Stejně jako v případě podmíněného bodu přerušení můžete zadat výraz, který bude kritériem zastavení při změně oblasti paměti. To vám umožní identifikovat chyby, které se objeví až po n-té aktualizaci proměnnou hodnotu.

Tečka stop Podle adresa. Stop na adrese je implementován, když je provedena instrukce umístěná v paměti na dané adrese. Tyto body jsou obvykle nastaveny-; pokud není možné nastavit normální bod přerušení na konkrétním řádku kódu z důvodu nedostatku zdrojového kódu pro odpovídající modul. Stejně jako u jiných typů bodů přerušení můžete zadat podmínky pro pozastavení provádění programu.

Tečka stop Podle načítání modul, jak název napovídá, zastaví provádění laděného programu při načtení zadaného modulu.

Skupiny body stop představují jednu z nejvýkonnějších a nejefektivnějších funkcí integrovaného debuggeru. Pomocí skupinového mechanismu lze libovolný bod přerušení aktivovat nebo deaktivovat jiným bodem přerušení, což vám umožňuje sestavit velmi složité algoritmy pro fungování skupin bodů přerušení, určené k detekci těch nejnepolapitelnějších a nejkonkrétnějších chyb.

Krok za krokemvýkonprogramy. Program lze spouštět postupně, řádek po řádku, pomocí příkazů Step Over nebo Trace Into (výchozí klávesy A respektive).

Příkaz Trace Into při provádění programu poskytuje vstup do volaných procedur a funkcí a příkaz Step Over je okamžitě provádí a prezentuje jako jednu akci. Tyto možnosti je vhodné použít po zastavení programu v určitém bodě jeho textu. Můžete také nařídit Delphi, aby spustilo program na místo, kde se aktuálně nachází kurzor – pomocí příkazu Run to Cursor (klávesa Run to Cursor

). Tato funkce je pohodlná A .

Použijte k přeskočení víceběžné smyčky, abyste nemuseli nepřetržitě mačkat tlačítkaPoužíváníoknoinspektor (data). Hodinky

Okno Watch lze použít ke sledování hodnot proměnných během běhu programu. Program musí být v režimu prohlížení programového kódu (tj. provádí se kterýkoli z bodů přerušení) – pouze v tomto případě bude obsah okna Sledování správný. V tomto okně můžete zadat nějaký výraz Object Pascal nebo zadat název definovaný v programu.Inspektoři (laděníLadit) jsou typem okna inspektora dat. Jsou výkonnější a snáze se používají než okno Sledování. V Inspektoru ladění můžete zobrazit obsah dat, která se skládají z mnoha jednotlivých prvků, jako jsou třídy a záznamy.

Použijte k přeskočení víceběžné smyčky, abyste nemuseli nepřetržitě mačkat tlačítkatýmyVyhodnoťteAModifikovat. Příkazy Evaluate a Modify vám umožňují prohlížet a upravovat obsah proměnných, včetně polí a záznamů, za běhu, zatímco je aplikace spuštěna v integrovaném ladicím programu. (Neposkytují však přístup k funkcím a proměnným mimo rozsah.)

PřístupNazásobníkhovory (VoláníZásobník) umožňuje zobrazit volání funkcí a procedur spolu s parametry, které jim byly předány, v pořadí, ve kterém byly provedeny až do určitého bodu provádění programu.

Pohledproudy (VláknoPostavení). Pokud vaše aplikace používá více vláken, vestavěný ladicí program může poskytnout informace o každém z nich.

ČasopisUdálosti (událostLog) - Toto je místo, kam debugger zapisuje informace o různých událostech. Mezi typy událostí, které mohou být protokolovány, patří spuštění a ukončení procesu a načtení modulu ladicím programem.

Oknoprocesor obsahuje pět informačních panelů: CPU, Memory Dump, Register, Flags a Stack. S jeho pomocí získá vývojář možnost zjistit, co se přesně v autě děje. Každý panel umožňuje sledovat důležité aspekty fungování procesoru během ladění.

Panel CPU zobrazuje operační kódy a mnemotechnické symboly pro aktuálně spuštěný rozebraný kód. Kód aplikace můžete zobrazit na libovolné adrese a náhodně vybrat novou instrukci pro aktuální provádění. To vám umožní studovat chování kódu sestavení programu. Zkušení vývojáři dobře vědí, že při kontrole vygenerovaného kódu sestavení se najde a odstraní mnoho chyb.

Kontextová nabídka okna CPU umožňuje přizpůsobit vzhled okna, zobrazit různé adresy, přejít na instrukci prováděnou v

ModerníHumanitárníUniverzita! 16

ModerníHumanitárníUniverzita

mimi- w . "Aviijimikáďi, niiit- lu-" pnyii. csiNall|) OCMOTpyORIGINÁL

kódu a v i ik ir n- i m" * i-* i h.if h mi. m m 11"m.i průtok ve kterém bude

otevření 11 něm.111." ".i iiih|m ,| iM.iimi i budu

Na naiifiiii Msmnnu i Himp mii + ihi zobrazit obsah libovolné oblasti námi i i;p<м мдср + пммп мм-нч (н.пьпредставлено по-разному: как Byle, Woid, nwnHD. uwnni). :>inul<>, Double nebo Extended. Můžete hledat a ii.immiii mi 1ed (tunová sekvence bajtů, upravená, unushchio d.tpio a přejít na další, nebo postupně lipo iyush.muya aktuální data jako ukazatel.

Účel složek Honji.loi a I lags je zřejmý: zobrazují a lze je změnit zpoždění procesoru.

Na panelu Zásobník můžete zobrazit paměť používanou aplikací jako paměť Můžete také měnit hodnoty a přejít na adresy.