Műveletek befelé, lépj tovább és kilépj
Most, miután leírta a töréspontokat és a karakterkészleteket, megmagyarázhatja, hogy a debuggerek hogyan hajtanak végre három figyelemre méltó műveletet - a Step Into, a Step Over és a Step Out. Nem a WDBG-ben kerülnek bevezetésre, mert a debugger főbb részeire szeretnék koncentrálni. Ezek a funkciók a hibakereső program két speciális nézetein belül1 működnek, amelyek lehetővé teszik az aktuális végrehajtható karakterlánc vagy parancs nyomon követését.
Mindezeket a műveleteket (Step Into, átlépni, és a Step Out) működnek eldobható töréspont, amely, mint emlékszik az előző szakaszok töréspont, hibakereső lemerült után aktiválódnak. A Debug Break menüpont megvitatásakor (lásd fent) egy másik esetet vettünk figyelembe, amelyben a debugger egyszeri töréspontokat használ a feldolgozás leállításához.
A Step Into művelet másképpen működik, attól függően, hogy a hibakeresés milyen szinten zajlik: a forrás vagy a szétszerelés szintjén. A forrásszintű hibakeresés során a hibakeresőnek az egyszeri megszakítási pontokra kell koncentrálnia, mivel egy magas szintű nyelv egy sorát az összeállító nyelv egy vagy több sorára fordítják le. Amikor a processzort lépésről-lépésre fordítja, az egyes gépi utasítások lépésről-lépésre, nem pedig forráskód-sorok lesznek.
Forrás nézet és szétszerelés nézet (szétszerelő kód ábrázolása a Szétszerelés ablakban). - transz.
Feldolgozási műveletek A Step Into, a Step Over és a Step Out nagyon egyszerűnek tűnik, de van egy olyan jellemző, amelyet figyelembe kell venni. Mit kell tennem, ha (a műveletek kezelésére létrehozott hibakeresőnél) már meg van adva egypontos megszakítási pontok ezekhez a műveletekhez, és rendszeres megszakítási pontot indítanak előttük? A hibakereső fejlesztőjeként két lehetősége van. Az első az, hogy csak a megszakítási pontokat hagyja el egy lövésnél (így csak dolgoznak). Egy másik lehetőség az egylépéses töréspontok törlése, amikor a hibakereső értesíti Önt arról, hogy egy rendszeres töréspont aktiválódott. A Visual C ++ hibakereső az utolsó funkciót használja.
Érdekes probléma a WDBG fejlesztésében
Általában kevés problémám volt a WDBG fejlesztésében. Azonban ideje megvitatni egy, véleményem szerint, nagyon érdekes problémát. Amikor a Visual C ++ hibakeresővel dolgozik, a Kimenet ablakban megjelenik a betöltött programmodulok teljes elérési útja. Mivel a WDBG-nek meg kellett adnia a maximális funkcionalitást, a Visual C ++ hibakeresőnek ez a tulajdonsága megismétlődik. De nem volt könnyű csinálni.
Az alábbi definíció LOAD_DLL_DEBUG_INFO szerkezetet (ez továbbításra kerül a hibakereső fogadásakor értesítés LOAD_DLL_DEBUG_EVENT) tartalmaz ipimageName mezőben. amely minden valószínűség szerint tárolja a betölthető modul nevét. Ez igaz, de a Win32 operációs rendszerek egyikének sem sikerült kitölteni ezt a mezőt, amikor a programba beolvassák.
typedef struct _LOAD_DLL_DEBUG_INFO
Mivel értesítést kap a LOAD_DLL_DEBUG_EVENT. ábrázolva a modul betöltődik a DBGHELP.DLL szimbólumgépbe. akkor úgy tűnt számomra, hogy a modul betöltése után (a memóriába) könnyű megtalálni a teljes nevét. A symGetModuieinfo API a megfelelő paraméter segítségével megkapja az alábbi IMAGEHLP_MODULE struktúrát. ahol van helye a modul teljes nevének (lásd ModuleName [32]).
Valójában minden úgy tűnik, hogy fordítva van: ez a szimbolikus gép betölti a modul szimbolikus adatait a megfelelő karakterfájlba (ebben az esetben a DBG fájlban). - Per
typedef struct _IMAGEHLP_MODULE
A furcsa az, hogy amikor SymGetModuieinfo függvény szimbólum információt a modul, a modul helyett a nevét vagy egy karakter visszatér DBG-fájl, vagy semmit sem ad vissza (azaz a modul nevét a visszaadott információk teljesen figyelmen kívül ..). Ez a viselkedés meglepőnek tűnhet, de csak első pillantásra. Amikor a LOAD_DLL_DEBUG_INFO struktúráját megkapta. az első ciklus (hFile típus) helyes volt, majd SymLoadModuie funkciót hívták a fogantyút az azonos típusú (hFile). Mivel soha nem töltöttem le a teljes fájlnevet a DBGHELP.DLL karaktergéppel, csak nézett a hFile leíróban megjelölt nyílt fájlra. hibakeresési információkat találtak benne, és elolvasták. A karakter gépnek soha nem volt szüksége a teljes fájlnév megismerésére.
Szerezd meg a betöltött modul azonos teljes nevét. Először arra gondoltam, hogy magam is használhatom a fájlleírót, hogy elérjem a modul export szakaszát, és jelezzék az ott található modul nevét. Ezenkívül a modul átnevezhető, és a neve az exportszakaszban helytelen lenne. Ez lehet EXE vagy DLL modul, amely nem tartalmazza az exportált modulok listáját. És még ha valahogy sikerült megtalálni a modul helyes nevét, a teljes neve (elérési út) elérhetetlen lenne.
Közös hibakeresési probléma
Miért nem tudok belépni a rendszerfunkciókba vagy meghatároznom a töréspontokat a Windows 98 rendszer memóriájában?
Tehát szeretné írni a saját hibakeresőt?
Az első lépés a WDBG megfontolása után. - Kiváló könyvet kap (Jonathan Rosenberg "Hogyan működnek a hibaelhárítók?"). Bár a hibakeresőnek nincs forráskódja, ez egy csodálatos bevezetés és vita a valódi problémákról, amelyeket a programozó hibakereső írása során tapaszt.
A PE formátumot és a CPU-t részletesen meg kell ismerni. amelyen dolgozol. A mellékelt CD tartalmazza a PECOFF.DOC. a legújabb PE specifikációkat a Microsofttól. További részletek a CPU-ról az Intel CPU kézikönyvekről érhetők el a www.intel.com címen.
A szétszerelő legjobb módja az Intel referencia kézikönyvek. Ezek tartalmazzák a parancsokra és a működési kódokra vonatkozó összes szükséges információt, valamint a műveleti kódok teljes térképét, amelyekről tudniuk kell, hogy a megfelelő számokat beillesszék a parancsokba. Számos szétszerelő forráskódja megtalálható az interneten. Mielőtt ténylegesen elkezdené írni, meg kell tanulnunk néhány szétszerelő forráskódját, hogy megkapjuk az alapvető ötleteket, és megnézzük, hogy más szakemberek hogyan kezelték ezt a feladatot.
Amint már említettük, a DBGHELP.DLL karakter gép elegendő néhány kiváló segédjavító segédprogramhoz, de nem elegendő egy valódi hibakereső számára. Mindig foglalkozik az PDB-fájlok formátumának fordított fejlődésével, és mindannyian remélhetjük, hogy a Microsoft egy napja nyílik hozzáférést az PDB-fájlokhoz.
WDBG: mi a teendő?
Telepítés után a WDBG hibakereső a tervek szerint működik. Azonban sok szempontból javítható. Az alábbiakban néhány ötlet található a WDBG javítására. Ha kiterjeszti a WDBG-t. hadd tudjam erről. Ezenkívül, amint azt már említettük a fejezetben. a programozó szakmai képességeinek csodálatos példája a saját kódjuk példája (nagyon hasznos, mondjuk a munkainterjúkra). Ha valamilyen alapvető tulajdonságot ad hozzá a WDBG-hez. akkor mutasd meg!
- Meg tudod csinálni a WDBG hibakereső felhasználói felülete (UI). Az első javítás, amit meg lehet tenni, az ezen interfész megvalósításának javítása. A felület már tartalmaz minden szükséges információt; akkor csak a legjobb módokat kell bemutatnia.
- A WDBG maga csak egyszerű, helyreállítási pontokat támogat. A BREAKPOINT.H BREAKPOINT.CPP és felvehet további érdekes fajta töréspont, mint a töréspont áthalad a számláló (hagyja száma töréspont) vagy töréspont kifejezést (kifejezés töréspontok), amelyre a megszakítás csak akkor következik be, ha a kifejezés igaz címkézett őket. Győződjön meg arról, hogy egy új töréspont segítségével CLocationBp funkció (amelyen keresztül kap a CE \ rializovanny kódot, és nem kell változtatni semmit WDBG).
- A WDBG-t nagy erőfeszítés nélkül kell kibővíteni. Több folyamat hibakeresésének támogatása (többfolyamat-hibakeresés). A legtöbb interfész úgy van felépítve, hogy egy folyamatazonosítási rendszeren dolgozzon, ezért csak a hibakeresési értesítés során követnie kell a folyamatot.
- A WDBG interfész úgy van megtervezve, hogy gyorsan távozhasson a távoli hibakeresésből és különböző CPU-kból, így a felület nagy része ugyanolyan lesz. Dinamikus távoli hibakeresési könyvtárak írása és a WDBG kiterjesztése annak érdekében, hogy a felhasználó választhassa ki a hibakeresést: a helyi vagy a távoli gépen.
- Végül, hogy a WDBG hibakereső valóban hasznos, mindig a legjobb szétszerelő és szimbólumgépet írhatja a C7 hibakereső szimbólumokra!
Ez a fejezet áttekintést nyújt arról, hogy hogyan működnek a hibakeresők. Különböző eszközök tanulmányozásával jelentősen javíthatja használatukat. Itt mutattuk be a Win32 Debugging API-t (32 bites Windows operációs rendszerek hibakeresési API-ja) és néhány támogató rendszert, például szimbolikus gépeket. Ön is megtudta, hogy léteznek más hibakeresők (kivéve a Visual C ++ hibakeresőt). Végül egy teljes hibakereső példája a WDBG, amely jól illusztrálja a hibakereső munkáját.
Tudta-e, hogy a komponens diagram egy objektum-orientált tervezési módszer, amely leírja a rendszer fizikai ábrázolását. A komponens diagram lehetővé teszi a rendszer fejlesztésének kialakítását, meghatározva az összetevők közötti függéseket.
HÍREK A FORUM
Az éter elméletének lovagjai