Acum, după descrierea punctelor de întrerupere și a caracterului mașinilor, puteți explica modul în care debuggerii implementează trei operații remarcabile - Step Into, Step Over și Step Out. Ele nu sunt implementate în WDBG, pentru că am vrut să mă concentrez asupra părților principale ale depanatorului. Aceste funcții funcționează în două vizualizări speciale1 ale programului depanat care vă permit să urmăriți șirul sau comanda executabilă curentă.
Toate aceste operațiuni (Step Into, Step Over și Step Out) lucrează cu puncte de întrerupere unice, care, după cum vă amintiți din secțiunile anterioare, sunt puncte de întrerupere care sunt resetate de către debugger după ce acestea sunt declanșate. Atunci când discutăm elementul de meniu Debug Break (a se vedea mai sus), a fost considerat un alt caz în care debuggerul utilizează puncte de întrerupere pentru a opri procesarea.
Pasul În operație funcționează diferit, în funcție de nivelul la care este efectuată depanarea: la sursă sau la nivelul de dezasamblare. Când se depanează la nivel de sursă, depanatorul trebuie să se concentreze asupra punctelor de întrerupere de o dată, deoarece o linie de limbaj de nivel înalt este tradusă în una sau mai multe linii ale limbii de asamblare. La traducerea procesorului într-un mod pas cu pas, instrucțiunile individuale ale mașinii vor fi pas-cu-pas, nu liniile codului sursă.
Vizualizarea surselor de vizualizare și dezasamblare (reprezentare cod dezasamblare în fereastra Dezasamblare). - Trans.
Operațiunile de procesare Pasul în, pasul peste și pasul pare destul de simplu, dar există o caracteristică care ar trebui luată în considerare. Ce ar trebui să fac dacă (în depanatorul creat pentru a gestiona aceste operații) au fost deja setate punctele de întrerupere pentru aceste operații și este declanșat un punct de întrerupere regulat înaintea lor? Ca dezvoltator de depanare, aveți două opțiuni. Primul este de a lăsa doar punctele de întrerupere pentru o singură lovitură (astfel încât numai acestea să funcționeze). O altă opțiune este să ștergeți punctele de întrerupere când debuggerul vă anunță că a declanșat un punct de întrerupere obișnuit. Debuggerul Visual C ++ utilizează ultima caracteristică.
O problemă interesantă de a dezvolta WDBG
În general, am avut puțină problemă în dezvoltarea WDBG. Cu toate acestea, este timpul să discutăm unul, în opinia mea, o problemă destul de interesantă. Când lucrați cu depanatorul Visual C ++, fereastra de ieșire arată căile complete la modulele de program încărcate. Din moment ce WDBG era obligat să ofere funcționalitatea maximă, această caracteristică a programului de depanare Visual C ++ este duplicat. Dar nu a fost ușor să o facem.
Următoarea definiție a structurii LOAD_DLL_DEBUG_INFO (este trecută la debugger la primirea notificărilor LOAD_DLL_DEBUG_EVENT) conține câmpul ipimageName. care, cel mai probabil, ar trebui să stocheze numele modulului încărcat. Acest lucru este adevărat, dar nici unul dintre sistemele de operare Win32 nu umple niciodată corect acest câmp atunci când este citit în program.
typedef struct _LOAD_DLL_DEBUG_INFO
Deoarece la primirea notificării LOAD_DLL_DEBUG_EVENT. în mod figurativ, modulul este încărcat în mașina de simbol DBGHELP.DLL. atunci mi sa părut că după încărcarea modulului (în memorie) este ușor să-i găsiți numele complet. API-ul symGetModuieinfo primește (prin parametrul corespunzător) structura IMAGEHLP_MODULE prezentată mai jos. unde există loc pentru denumirea completă a modulului (a se vedea ModuleName [32]).
De fapt, totul pare a fi invers: această mașină simbolică încarcă informațiile simbolice ale modulului în fișierul de caractere corespunzător (în acest caz, fișierul DBG). - Per
typedef struct _IMAGEHLP_MODULE
Lucru ciudat este că, atunci când funcția SymGetModuieinfo returnează informațiile simbol al modulului, modulul în loc de numele sau numele unui personaj returnează DBG-fișier, sau nimic nu este returnat (de exemplu, numele modulului în informațiile returnate este complet trecut cu vederea ..). Acest comportament poate părea surprinzător, dar numai la prima vedere. Când a fost recepționată structura LOAD_DLL_DEBUG_INFO. primul său pe termen (tip hFile) a fost corectă, iar apoi funcția SymLoadModuie a fost chemat cu mânerul de același tip (hFile). Deoarece niciodată nu am descărcat numele de fișier complet pe mașina de caractere DBGHELP.DLL, ea arăta doar în fișierul deschis indicat de descriptorul hFile. a găsit informații de depanare în el și le-a citit. Mașina de caractere nu avea nevoie să cunoască întregul nume de fișier.
Obțineți același nume complet al modulului încărcat. La început m-am gândit că pot să folosesc eu singur descriptorul fișierului pentru a accesa secțiunea de export a modulului și pentru a raporta numele modulului găsit acolo. În plus, modulul ar putea fi redenumit, iar numele acestuia în secțiunea de export ar fi incorect. Acesta ar putea fi un modul EXE sau DLL care nu conține o listă de module exportate. Și chiar dacă a reușit cumva să găsească numele corect al modulului, numele său complet (calea) ar fi inaccesibil.
Problemă obișnuită de depanare
De ce nu pot intra în funcțiile sistemului sau nu pot stabili puncte de întrerupere în memoria de sistem Windows 98?
Deci, doriți să vă scrieți propriul depanator?
Primul pas care trebuie luat după examinarea WDBG. - Obțineți o carte excelentă (Jonathan Rosenberg "Cum lucrează Debuggerii"). Deși nu există cod sursă pentru depanator, aceasta este o introducere minunată și o discuție despre problemele reale pe care le va întâlni programatorul atunci când scriu un depanator.
Este necesar să cunoașteți în detaliu formatul PE și CPU-ul specific. pe care lucrați. CD-ul însoțitor conține PECOFF.DOC. ultima specificație pentru fișierele PE de la Microsoft. Mai multe detalii pot fi învățate de la procesor pe manualele procesorului Intel disponibile pe www.intel.com.
Cea mai bună modalitate de a scrie un dezasamblator este cu manualele de referință Intel. Acestea conțin toate informațiile necesare privind comenzile și codurile de operare, precum și o hartă completă a codurilor de operare pe care trebuie să le cunoașteți pentru a include numerele corespunzătoare în comenzi. Codul sursă pentru mai multe dezasamblători poate fi găsit pe Internet. Înainte de a începe să scrieți, este necesar să studiați codurile sursă ale mai multor dezasamblători pentru a obține ideile de bază și pentru a vedea cum s-au confruntat alți specialiști cu această sarcină.
Așa cum am menționat deja, mașina caracter DBGHELP.DLL este suficientă pentru unele utilități de depanare auxiliare excelente, dar nu este suficientă pentru un debugger real. Puteți întotdeauna să vă ocupați de dezvoltarea inversă a formatului de fișiere PDB și cu toții sperăm că într-o zi Microsoft va avea acces deschis la fișierele PDB.
WDBG: ce trebuie să faceți în continuare?
După instalare, depanatorul WDBG funcționează conform destinației. Cu toate acestea, acesta poate fi îmbunătățit în multe moduri. Mai jos sunt câteva idei pentru îmbunătățirea WDBG. Dacă extindeți WDBG. dați-mi voie să știu despre asta. În plus, așa cum am menționat deja în capitol. o ilustrare minunată a abilităților profesionale ale programatorului sunt exemple de cod propriu (foarte util, de exemplu, pentru interviuri de lucru). Dacă adăugați proprietăți esențiale la WDBG. atunci trebuie să-i arăți!
- Puteți face interfața cu utilizatorul (UI) a depanatorului WDBG. Prima îmbunătățire care se poate face este îmbunătățirea implementării acestei interfețe. Interfața conține deja toate informațiile necesare; ar trebui să proiectați cele mai bune moduri de ao prezenta.
- WDBG în sine suportă doar puncte limită simple, de localizare. Cu BREAKPOINT.H BREAKPOINT.CPP și pot adăuga alte tipuri interesante de puncte de întrerupere, cum ar fi puncte de oprire trece la contorul (sări peste breakpoint COUNT) sau expresii Breakpoint (expresie valori critice), pentru care întrerupere apare numai în cazul în care expresia este adevărată le-a etichetat. Asigurați-vă că veți obține un nou punct de întrerupere folosind funcția CLocationBp (prin care obține codul CE \ rializovanny și nu trebuie să se schimbe nimic în WDBG).
- Ar trebui să puteți extinde WDBG fără mult efort. Pentru a sprijini depanarea mai multor procese (depanare-> mai multe procese). Majoritatea interfețelor sunt construite pentru a lucra la o schemă de identificare a procesului, deci trebuie doar să urmăriți cu ce proces lucrați în timpul notificării de depanare.
- Interfața WDBG este construită pentru a vă permite să mergeți rapid la depanare la distanță și la diferite CPU-uri, lăsând partea principală a interfeței să funcționeze aproape la fel. Scrieți biblioteci dinamice de depanare la distanță și extindeți WDBG pentru a permite utilizatorului să aleagă unde să se depaneze: pe mașina locală sau la distanță.
- În cele din urmă, pentru a face debuggerul WDBG foarte util, puteți scrie întotdeauna cea mai bună mașină de dezasamblare și simbol pentru simbolurile de depanare C7!
Acest capitol oferă o prezentare generală a modului de funcționare a programelor de depanare. Studiind diferite instrumente, puteți îmbunătăți în mod semnificativ utilizarea lor. Aici a fost prezentat API-ul de depanare Win32 (API de depanare a sistemelor de operare Windows pe 32 de biți) și unele sisteme suport, cum ar fi, de exemplu, mașinile simbolice. De asemenea, ați aflat despre existența unor alți debugeri (cu excepția programului de depanare Visual C ++). În sfârșit, un exemplu de depanator complet este WDBG, care ilustrează bine lucrarea de depanare.
Știați că diagrama Component este o metodă de proiectare orientată pe obiecte care descrie reprezentarea fizică a sistemului. Diagrama componente vă permite să determinați arhitectura sistemului dezvoltat, stabilind dependențele dintre componente.
ȘTIRI ALE FORUMULUI
Cavalerii teoriei eterului
Articole similare
Trimiteți-le prietenilor: