Bod zlomu - Breakpoint
Ve vývoji softwaru je zarážkou záměrné zastavení nebo pozastavení místa v programu , které bylo zavedeno pro účely ladění . Někdy se také jednoduše označuje jako pauza .
Obecněji je zarážka prostředkem k získání znalostí o programu během jeho provádění. Během přerušení je programátor kontroluje testovací prostředí ( univerzálních registrů , paměti , protokoly, soubory , atd.) Zjistit, zda je tento program funguje, jak se očekávalo. V praxi se bod zlomu skládá z jedné nebo více podmínek, které určují, kdy má být provádění programu přerušeno.
Obsah
Podmínky bodu zlomu
Body přerušení se nejčastěji používají k přerušení běžícího programu bezprostředně před provedením instrukce specifikované programátorem . Toto se často označuje jako zarážka instrukce .
Lze použít i jiné druhy podmínek, jako je čtení, zápis nebo úprava konkrétního umístění v oblasti paměti. To se často označuje jako podmíněný bod zlomu , bod zlomu dat nebo bod sledování .
Body přerušení lze také použít k přerušení provádění v určitém čase, při stisknutí klávesy atd.
Inspekční nástroje
Když je zasažen bod zlomu, používají se různé nástroje ke kontrole stavu programu nebo jeho změně. Stohovou stopu každého vlákna lze použít k zobrazení řetězce volání funkcí, které vedlo k pozastavené instrukci. Seznam hodinek umožňuje zobrazit hodnoty vybraných proměnných a výrazů . Mohou existovat také nástroje pro zobrazení obsahu registrů , načtených programových modulů a dalších informací.
Implementace
Hardware
Mnoho procesorů zahrnuje hardwarovou podporu pro zarážky (obvykle instrukční a datové zarážky). Jako příklad poskytuje architektura instrukční sady x86 hardwarovou podporu pro zarážky pomocí jejích ladicích registrů x86 . Takový hardware může zahrnovat omezení, například neumožňuje zarážky na instrukcích umístěných ve slotech zpoždění větví . Tento druh omezení je dán mikroarchitekturou procesoru a liší se od procesoru k procesoru.
Software
Bez hardwarové podpory (a v prostředích s více úkoly) musí debuggery implementovat zarážky v softwaru. Pro zarážky instrukcí se jedná o poměrně jednoduchý úkol nahrazení instrukce v místě zarážky buď:
- instrukce, která přímo volá debugger (např. systémové volání ) nebo
- neplatná instrukce, která způsobí úmyslné přerušení programu (který je poté zachycen / zpracován ladicím programem)
Tuto techniku může být obtížnější implementovat v multitaskingových systémech využívajících sdílené úložiště programu (přerušení může nastat v jiném vlákně, což vyžaduje vzkříšení původní instrukce pro toto vlákno). Také pokud je program umístěn v chráněné paměti, může být zabráněno přepsání pokynů.
Alternativně,
- instrukční sada simulátor může implementovat nepodmíněné nebo podmíněné zarážky, pouhým vložením odpovídajícím stavu zkoušky v rámci svého normálního cyklu programu - to také samozřejmě umožňuje neinvazivní zarážky (na pouze pro čtení programů například).
- Interpretované jazyky mohou ve svém programovém cyklu efektivně využívat stejný koncept jako výše.
- „Instrumentování“ veškerého zdrojového kódu dalšími zdrojovými příkazy, které vydávají funkci, která vyvolá interní nebo externí ladicí podprogram, je dalším běžným přístupem. Tato metoda zvyšuje binární velikost a může nepříznivě ovlivnit normální přidělení paměti a obslužné rutiny výjimek . U některých překladačů existují možnosti „ladění“, které tuto techniku implementují poloprůhledně.
Některé debuggery umožňují před obnovením úpravy registrů nebo programových proměnných v paměti, což účinně umožňuje zavedení „ručně kódovaných“ dočasných přiřazení pro účely testování. Podobně lze často přeskočit pokyny programu, aby se určil účinek změn logiky programu - což umožňuje přímé odpovědi na otázky týkající se provádění programu (tj. Bez předpokladů nebo dohadů). V mnoha případech může jít o jedinou praktickou metodu testování obskurních „událostmi řízených“ chybových podprogramů, které se zřídka, pokud vůbec, provedou - bez dalšího rizika opuštění dočasných změn zdroje. Ruční zadání umístění obnovení v pozastaveném programu lze použít k zadání jinak zřídka provedené části kódu (například konkrétní obslužné rutiny stavu hardwaru).
Implementace datových hraničních bodů v softwaru však může výrazně snížit výkon laděné aplikace - protože používá další zdroje na stejném procesoru. To je však během testování normálně přijatelné a množství informací dostupných z debuggeru není omezeno omezeními ladicích dat známých hardwaru. Například softwarová implementace může shromažďovat data logické cesty na úrovni programu / podprogramu / instrukce, aby výrazně rozšířila to, co by mohla být uložena konkrétní hardwarovou platformou pro kontrolu. Metoda simulace sady instrukcí značně snižuje režii ve srovnání s (opakovanou) metodou nahrazování instrukcí, což také omezuje vynechání mezipaměti .
Některé implementace programovacího jazyka vystavují své ladicí funkce pro použití v jiných programech. Například některé dialekty FORTRAN mají ATpříkaz, který měl původně fungovat jako zarážka instrukce.
Python implementuje debugger přístupný z programu Python. Tato zařízení mohou být a jsou zneužívána k tomu, aby fungovala jako příkaz COMEFROM .
Dějiny
Hraniční hodnoty vynálezu byly pro ENIAC , jeden z prvních digitálních počítačů, vynalezeny programátorkou Betty Holbertonovou . V počátečním návrhu ENIAC byl tok programu nastaven připojením kabelů z jedné jednotky do druhé. Aby se program v určitém bodě zastavil, byl odstraněn kabel, který se nazývá zarážka .
Zarážky stroje Brzy mainframové počítače, jako například IBM / 360 , měly přepínače / vytáčení konzoly, které umožňovaly zarážky na konkrétních adresách paměti instrukcí a poskytovaly operaci „jednoho cyklu“, což umožňovalo sledovat obsah registrů a paměti přímo na kontrolách konzoly. Příchod multitaskingu omezil použití této možnosti, protože celý stroj byl zastaven.
Neinteraktivní zarážky Programátoři použili opravy strojového kódu k implementaci jednotlivých destruktivních zarážek, které způsobily výpis jádra od počátků počítačů. Výpis jádra poskytoval stav registrů a paměti v přesný okamžik úmyslného „pádu“.
Interaktivní zarážky Příchod konzol dálnopisného psaní v 60. letech umožnil více interaktivních funkcí ladění příkazového řádku , ale až na začátku 70. let a příchodem všudypřítomných video monitorů připojených k sálovým počítačům se plně interaktivní ladění na celou obrazovku v prostředí multitaskingu stalo realitou. To také umožňovalo postupné provádění programu skutečným způsobem animace programu s možností současného zobrazení volitelných změn registru a paměti. Zpočátku byl tento typ animace na úrovni rozebraného nebo dekompilovaného strojového kódu, ale později pokročil na animaci na úrovni zdroje HLL .
Viz také
- ODCHOD
- Animace programu (krokování)
- SIMMON