[OSy] Zamrzani

[Martin Decky]

Hezky den,

souhlasim, ze ladici schopnosti samotneho msimu nejsou uplne nejbohatsi. 
Z principu jeho funkce neumoznuje napriklad zpracovat debug information 
z prelozeneho kernelu (musite si vygenerovat mapfile a disassebly a 
porovnavat adresy s nimi), ale i tak umoznuje ladit kernel o mnoho radu 
pohodlneji nez v pripade, kdy byste programovali na holem zeleze.

Chybejici podporu breakpointu na kod muzete bud obejit rucnim vlozenim 
instrukce DINT, nebo (pokud si nemuzete dovolit menit kod kernelu) 
vlozenim podminky primo do msimu.

Podobne breakpoint na pristup do pameti muzete udelat zmenou msimu nebo 
alespon zpetne analyzou vystupu trace rezimu. Co se tyce prepisovani 
kodu kernelu, tak tam ten test muze byt velmi jednoduchy, proste budete 
hlidat, zda nekdo nezapisuje do adres odpovidajicich .text.


Metoda ladicich vypisu primo v kodu kernelu (jak napriklad psala slecna 
Dufkova) je take mozna, ale zrovna u veci, kdy se jedna o nejaky race 
condition, vede k tomu, ze se zmeni usporadani kodu a dany race se bud 
projevovat prestane, nebo se presune nekam jinam. Zde je naopak potreba 
vyuzit neocenitelne vlastnosti simulatoru -- se stejnym kodem a daty 
bezi vzdy presne stejne.

Bohuzel v techto situacich ani presne nalezeni mista, kde se zapisuje 
nejaka hodnota na spatne misto do pameti, nemusi vezt k nalezeni prave 
priciny problemu, protoze to muze byt jen projev zavlecene chyby 
(obzvlaste ve strukturach memory managementu nebo pri synchronizaci). 
Nezbyva nez vylucovaci metodou najit priblizne misto kodu, kde se neco 
dela spatne, a potom dukladnym prozkoumanim zdrojaku zjistit skutecnou 
pricinu. Ze jste ji nasli, poznate typicky podle toho, ze dovedete nejen 
rici, ze se chyba uz neprojevuje, ale taky naprosto presne vite, v cem 
byl vlastne problem.


V TLB Refill handleru neni potreba explicitne zakazovat preruseni, 
protoze ta jsou zakazana od zacatku. Naopak je vhodne preruseni vubec 
nepovolovat, aby bylo mozne rutinu prerusit jen jinym TLB Refillem. Pro 
usnadneni cele logiky je navic vhodne, aby behem provadeni TLB Refillu 
zadny dalsi TLB Refill nemohl nenastat -- bud diky tomu, ze k veskerym 
datum pristupuje handler pres nemapovanou pamet, nebo za pouziti wired 
TLB zaznamu (viz registr CP0 Wired).


Upozorneni: Bez alespon zbezne znalosti assembleru MIPSu se skutecne 
neobejdete (a bude to platit i pro treti zadani, prestoze by se mohlo 
zdat, ze to uz bude v user space a tedy "daleko od procesoru").


M.D.