OS Awareness
Simics OS Awareness är en Simics-modul som förstår datastrukturer och abstraktioner för operativsystemet som körs på Simics målsystem. Med OS awareness vet Simics och Simics debugger om kernel space, user space, processer, trådar och uppgifter.
Fundamentalt sett utför OS awareness två uppgifter: live-spårning av händelser när de inträffar och undersökning av det omedelbara tillståndet i operativsystemet. Live-spårning av händelser innebär att OS awareness upptäcker när operativsystemet utför ett uppgiftsbyte, när programvaran gör ett systemanrop eller när avbrott inträffar. Det vanligaste sättet att upptäcka sådana händelser är att vänta på avbrott i målsystemet – så länge inga avbrott sker körs samma programvara på användarnivå. När ett avbrott inträffar tar operativsystemet över och den pågående processen anses ha bytts ut. När operativsystemet återvänder tillbaka till användarutrymmet anses någon process ha kopplats in.
Live tracking fastställer när något händer, men för att fastställa vad som hände krävs det att man undersöker operativsystemets ögonblickliga tillstånd. Till exempel, när ett avbrott utlöses, vilka är de aktiva trådarna på den processor som tog emot avbrottet? För att avgöra detta måste OS awareness känna till strukturen i OS:s köer för pågående och väntande processer, innehållet i uppgiftsstrukturerna eller processkontrollblocken och andra datastrukturer. Förutsatt att detta har konfigurerats korrekt kan OS awareness sedan gå igenom listorna i målminnet och bestämma namnet på den för närvarande aktiva processen på en viss processor, alla befintliga processer, dynamiskt inlästa programvarumoduler och deras omlokaliseringsadresser och allt annat av intresse.
Om det exakta innehållet i task structs och offsets för särskilda fält kan variera mellan olika operativsystembyggen och versioner, måste OS awareness konfigureras innan det kan användas. Oftast är det möjligt att bestämma parametrarna för OS awareness genom att titta på en symboltabell eller en kärnfil med felsökningsinformation från OS-bygget. Det finns dock operativsystem där de exakta parametrarna inte kan bestämmas förrän vid körning, och i sådana fall måste konfigurationen vänta tills målsystemet har startat upp. I vilket fall som helst kan uppsättningen parametrar sparas när de väl har fastställts och användas nästa gång samma målkonfiguration körs.
Användningen av parameterfiler gör det möjligt att låta OS awareness-konfigurationer distribueras tillsammans med de OS-avbildningar som de hänvisar till. Detta innebär att ett plattformsteam kan bygga en OS-avbildning, konfigurera OS-kännedom för den, spara parametrarna och förse sina användare med OS och dess OS-kännedomsparametrar utan att behöva tillhandahålla symbolfiler eller felsökningsinformation. Filen med OS awareness-parametrar är helt enkelt en del av den tillhandahållna programvarustapeln, och den aktiveras i de startskript som används för att starta Simics. Systemets användare behöver inte veta hur man konfigurerar OS awareness – de får det bara att fungera så snart de startar de tillhandahållna målsystemuppsättningarna. Parametrar för OS awareness sparas också i Simics checkpoint-filer, så att OS awareness fortsätter att fungera över checkpoint- och återställningsoperationer.
OS awareness gör det möjligt att få Simics-funktioner att fungera endast på en viss delmängd av programvarustacken, t.ex. genom att ha brytpunkter som endast sätts i en viss process, eller genom att spåra endast minnesåtkomster som utförs av kärnan och inte av uppgifter på användarnivå. Ett användarskrivet Simics-tillägg eller skript kan lyssna på händelserna från OS awareness och vidta åtgärder baserat på vilken programvara som för närvarande körs i målsystemet. Det är möjligt att be OS awareness-systemet om meddelanden endast för en viss process, eller att se alla åtgärder för alla processer.
Systemet OS awareness i Simics arbetar med begreppet nodträd. Varje nod i trädet representerar en abstraktionsnivå i OS-processmodellen. Typiskt sett är den översta noden själva operativsystemet, som sedan delas upp i uppgifter på kärn- och användarnivå. I ett operativsystem som Linux innehåller varje uppgift på användarnivå en eller flera trådar. I kärnan skiljer OS awareness normalt kärnans trådar från den inaktiva uppgiften, eftersom det hjälper till att förklara målets exekveringstid. Figur 3.3 visar ett exempel på ett nodträd från ett barebones Linux-system.
Figur 3.3. OS awareness tree.
I Simics CLI och debugger GUI används processfrågor för att hitta processer av intresse. Dessa förfrågningar kan matcha processnamn, process-ID-nummer eller andra egenskaper som görs tillgängliga av OS awareness. I de flesta fall räcker namnet på en process för att identifiera den, men i komplexa system behövs mer komplexa matchningar som till exempel ”processen som heter foo på brädet som heter bar”. I ett långvarigt system där ett visst program körs många gånger kan process-ID användas för att identifiera en viss start av en process.
Simics OS awareness har stöd för nästlade operativsystem för att hantera OS awareness för hypervisor-baserade system. I ett system med en hypervisor är det nödvändigt att spåra schemaläggningen av gästoperativsystem på målprocessorkärnorna. När det aktiva operativsystemet på en kärna har fastställts är det möjligt att sedan tillämpa OS awareness för det operativsystemet för att fastställa den aktiva processen eller tråden. Ett enda träd används alltså för hela systemet, med rötter i hypervisorn.
Detaljerna av vad OS awareness kan spåra och upptäcka om målprogramvarustacken varierar beroende på gästoperativsystemet och hur mycket arbete som lagts ner på att bygga OS awareness för det.
Vid jämförelse med de system för OS awareness som används med hårdvarubaserade (JTAG) felsökningsverktyg är simulatorns förmåga att exakt spåra uppgiftsbyten unik. Sådana funktioner har visat sig vara opraktiska att implementera i hårdvarubaserade felsökare, eftersom de skulle medföra en betydande overhead och överväldiga tillgången till brytpunkter i hårdvaran. Inspektionen av det momentana tillståndet är i huvudsak samma som en hårdvarudebuggares inspektion av systemtillståndet efter att ha stoppat systemet, och faktiskt har samma kod som används för hårdvarudebuggare använts med Simics för att bestämma fakta som flyttningsadresser för dynamiskt inlästa moduler.
En agentbaserad debugger behöver inte ha kännedom om operativsystemet, eftersom den körs inne i målsystemet och kan använda operativsystemets API:er för att fråga måloperativsystemet om pågående uppgifter, inlästa moduler och annan information.