SE524799C2 - Förfarande och dataprogram för debuggning av en programkod - Google Patents

Description

25 30 35 524 799 2 Distribuerade realtidssystem tillför ytterligare en komplexitetsnivå, efter- som processer då kan exekveras samtidigt på olika noder, vilket gör tro- gen återexekvering än mer komplicerat.

Tai et al.:"Debugging Concurrent Ada Programs by Deterministic Execu- tion”, IEEE Transactions on Software Engineering, Vol. 17, No. 1, Janua- ry 1991, presenterar ett språkbaserat angreppssätt för deterministisk ex- ekveringsdebuggning av samtidiga program skrivna i programspråket Ada. Förfarandet som visas av Tai et al. innefattar definiering av synkro- niseringssekvenser för ett program som skall debuggas. Ett språkbaserat återuppspelningsverktyg används därefter för att omforma programmet som ska debuggas till ett något annorlunda program som sedan kan exe- kveras på ett reproducerbart sätt genom att använda synkroniseringsse- kvenserna som indata. Omformningen av programmet innefattar inskjut- ning av en eller flera kontrollpaket i programmet för att styra exekvering- en av de olika sekvenserna i programmet.

Leblanc och Mellor-Crummy: "Debugging Parallel Programs with Instant Replay", lEEE Transactions on Computers, Vol. C-36, No. 4, April 1987, visar ett förfarande för debuggning av parallella program. Under pro- gramexekveringen sparas den relativa ordningen mellan signifikanta händelser när de inträffar, men inte de data som är associerade till varje händelse. Interaktioner mellan processer modelleras som operationer på delade objekt. Varje process spelar in versionsnummret för varje delat objekt som det accessar. En partiell ordning för accesserna till varje ob- jekt spelas in, så att ordningen mellan processerna som läser en viss version av ett objekt, inte behöver etableras. Under återuppspelning av programmet i en ekvivalent virtuell maskinmiljö återberäknar varje pro- cess sina utdatavärden och tillhandahåller därmed indata till andra pro- cesser. Som anförs av författarna själva är förfarandet, som de kallar ln- stant Replay, inte lämplig för realtidssystem på grund av svårigheten att simulera ekvivalenta virtuella maskiner.

McDowell och Helmbold: Debugging Concurrent Programs, ACM Com- puting Surveys, Vol. 21, No. 4, December 1989, beskriver tre generella tekniker för debuggning av samtidiga program. Metoder för att undvika 10 15 20 25 30 35 524 g99 probeffekten, dvs. att observationen i sig oundvikligen förändrar pro- grammets beteende, diskuteras. Dessa innefattar att proberna, dvs. de delar av programmet som används för debuggningsåndamål, permanent är på plats och användning av hårdvaru-"krokar". lnget förfarande som fungerar tillfredsställande för realtidssystem föreslås.

Thane och Hansson:"Using Deterministic Replay for Debugging of Distri- buted Real-Time Systems", i 12th Euromicro Conference on Real-Time Systems, pp. 265-272, Stockholm, June 2000, IEEE Computer Society, föreslår ett system för debuggning av distribuerade realtidssystem, vilket även kan användas för mindre komplicerade realtidssystem.

Systemet som föreslås av Thane och Hansson har tre huvudfunktioner: - inspelning av alla signifikanta händelser under programexe- kvenng - upprättande av historien genom analysering och korrelering av de inspelade händelserna ' - återuppspelning av historien genom användning av en an- passad off-lineversion av kärnan.

De inspelade händelserna kan vara processbyten, avbrott och interaktio- ner med externa processer. Historien upprättas som en tidslinje som re- presenterar den inspelade exekveringen. Når historietidslinjen har upprättats så matas den till en instruktionsnivåsimulator där den kan åter- uppspelas.

Ett problem med debuggning inträffar när samma instruktion exekveras flera gånger. Samma programräknarvärde används då vid mer är. ett till- fälle under exekveringen av programmet, så att programräknaren inte är en unik identifierare av tidpunkten då en händelse skedde. Detta inträffar t.ex. när programmet innehåller en loop som exekveras ett antal gånger beroende på en villkorsuppsättning. Samma sak inträffar om en rekursiv rutin används. Den rekursiva rutinen anropar sig själv ett antal gånger, till exempel tills en parameter uppnår ett visst värde. l dessa fall kommer samma programräknarvärde att återuppstå för varje loop, eller varje gång den rekursiva rutinen anropas. Därför kan programräknarvårdet i sig själv inte unikt identifiera punkten i programexekveringen där ett processbyte eller ett avbrott inträffade. 10 15 20 25 30 35 524 7949 Thane och Hansson föreslår i den ovan citerade artikeln att man sparar all information som lagras av kärnan vid kontext-byten, lika väl som stack- och programräknarregister som hänför sig till uppgiften. Denna sparade kontext används som en unik markör för programmet. En nack- del med denna typ av unika markör är att den kan vara beräkningsmäs- sigt krävande att beräkna och/eller att den kräver avsevärt minne för att sparas. Dessutom garanteras den inte att vara unik i strikt mening. Ett alternativt angreppssätt skulle kunna vara att använda hårdvaru- eller mjukvaruinstruktionsräknare. Tyvärr är sådana räknare normalt inte till- gängliga. Att lägga till speciell hårdvara kommer vara kostsamt och en mjukvaruräknare kommer vara beräkningsmässigt krävande.

Ofta innefattar program en eller flera instruktionssekvenser som enbart används för debuggningsändamål. Under exekvering ignoreras helt en- kelt dessa instruktioner. Detta introducerar en skillnad mellan debugg- ningsituationen och exekveringssituationen, vilket utgör ett ytterligare problem vid debuggning av realtidssystem. Ett program som innefattar sådana debuggningsinstruktioner kommer att ta längre tid att exekvera i debuggningsituationen, och ändrar således programmets beteende. Det- ta leder till en probeffekt, dvs. genom att observera systemet så ändrar vi det oundvikligen. l Thane H et al. "Debugging using time machines; Replay your embed- ded systems history" Nov 2001, ln Real-time & embedded computing conference, Milan, beskrivs det som presenteras i ingressen till kravet 1. ÄNDAMÅLET MED UPPFlNNlNGEN Ett ändamål med uppfinningen är att möjliggöra debuggning av datorsy- stem från enskilda program med avbrottsstörningar till multiprocess och distribuerade realtidsdatorsystem.

SAMMANFATTNING AV UPPFlNNlNGEN Detta ändamål uppnås med den föreliggande uppfinningen genom ett förfarande för debuggning av enkel- och multiprocessrealtidssystem som 10 15 20 25 30 35 5245799 exekveras på en enkelprocessor, multiprocessor eller distribuerat sy- stem, och innefattar stegen: o exekvering av ett datorsystem som innefattar den programkod som ska debuggas o inspelning av alla signifikanta händelser under exekveringen av systemet o upprättande av en historia genom analysering och korrelering av de inspelade händelserna, varvid en brytpunkt insätts vid varje sig- nifikant händelse o återuppspelning av historien i en debugger som stödjer brytpunkter och makron, ändring av systemets tillstånd vid programpositioner där brytpunkter har insatts för att emulera den inspelade exekve- ringen, kännetecknat av att varje brytpunkt i programmet definieras av en brytpunktsidentifierare som innefattar en väsentligen unik markör, vilken markör innefattar en checksumma. Ändamålet uppnås även av en datorprogramprodukt för användning vid debuggning av en programkod i ett datorsystem, varvid nämnda datorsy- stem innefattar o medel för inspelning av alla signifikanta händelser vid exekvering av systemet o medel för att addera en brytpunktsidentifierare för varje brytpunkt o medel för att upprätta en historia genom analysering och korrele- ring av de inspelade händelserna, varvid nämnda datorprogram är anordnat att förändra systemets tillstånd vid positioner iprogram- met som kräver debuggning medan historien återuppspelas, och kännetecknad av att medlet för addering av en brytpunktsidentifiera- re är anordnat att addera en brytpunktsidentifierare som innefattar åt- minstone en väsentligen unik markör som innefattar en checksumma, och att den ytterligare innefattar o medel för återexekvering av den upprättade historien o medel för att vidta lämpliga åtgärder när en brytpunktshändelse in- träffar för att säkra att historien troget återexekveras.

Med "väsentligen unik" avses att markören ska ha en form som kommer att tjäna som en unik identiflerare för praktiskt taget alla situationer som kan inträffa. 10 15 20 25 30 35 524 799 e Företrädesvis är datorprogramprodukten anordnad att àteruppspela hi- storien i det ursprungliga systemet, och kännetecknas av att medlet för återexekvering av historien som initieras vid klockslagsinitierade sche- mahändelser, systemanrop och avbrott, är anordnat att exekveras vid åtminstone en brytpunkt.

Uppfinningen möjliggör debuggning av multiprocess och distribuerade realtidsdatorsystem som innehåller loopar och rekursiva anrop. Uppfin- ningen kan utnyttja varje standarddebugger som stödjer brytpunkter och insättning av makron vid brytpunkterna, inte enbart instruktionsnivàsimu- latorn som nämns av Thane och Hansson.

Debuggningsförfarandet enligt uppfinningen kräver inte förändring av pro- grammet som ska debuggas.

Uppfinningen hanterar sekvenser av debuggningskommandon vid de- buggning av program som exekveras i ett realtidsdatorsystem.

Uppfinningen hanterar icke-terminerande och terminerande program vid debuggning av realtidsdatorsystem. l en föredragen utföringsform innefattar brytpunktsidentifierarna pro- gramräknaren och systemtiden tillsammans med den väsentligen unika markören.

Företrädesvis innefattar den väsentligen unika markören en av följande eller en kombination därav: ø en checksumma innefattande summan av innehållet i samtliga re- gister och/eller delar av användarstacken. Denna lösning har för- delen att kompilatorn inte behöver modifieras. Hàrdvaru- eller mjukvaruinstruktionsräknare behövs inte. Detta gör den föreslagna lösningen relativt billig samtidigt som den möjliggör bättre optime- ring av den exekverade programkoden jämfört med vad som skulle vara möjligt med användning av mjukvaruinstruktionsräknare. o En stackpekare och/eller instruktionsräknare (IC). Detta möjliggör utnyttjande av eventuellt tillgängliga HW resurser, vilket är fördel- aktigt framför mjukvarulösningar ur ett resursperspektiv. 10 15 20 25 30 35 524 799 7 Företrädesvis innefattar förfarandet steget exekvering av förändringse- mulerande kod vid åtminstone en brytpunkt för att emulera förändringen i programflödet som inspelats under exekveringen av systemet.

Förfarandet och programvaruprodukten enligt uppfinningen möjliggör för- ändringar av och tillägg till koden för att lägga till debuggningsinstruktio- ner eller testa programkorrigeringar. Systembeteendet som svar på änd- rad indata eller ändrad kod kan undersökas.

KORT BESKRIVNING AV RITNINGARNA I det följande kommer uppfinningen att beskrivas i närmare detalj enbart såsom ett exempel och med hänvisning till bifogade ritningar, i vilka Figur 1 illustrerar ett enkelt datorsystem i vilket uppfinningen kan använ- das.

Figur 2 visar den Konfigurering som används vid debuggning i enlighet med en utföringsform av uppfinningen Figur 3 visar ett förenklat exempel av en processintersekvensering i ett multiprocessrealtidssystem.

Figur 4, 5 och 6 visar schematiskt de delar av en exekverande kärna som används för att avgöra vilken process som skall exekveras vid varje given tidpunkt, dvs. för att reproducera processintersekvensering såsom den som visas i figur 3.

DETALJERAD BESKRIVNING AV UTFÖRINGSFORMER Uppfinningen kan användas i ett distribuerat system innefattande ett an~ tal noder. Varje nod är ett självständigt datorelement, med en central processenhet (CPU), minne, nätverksaccess, en lokal klocka och in/ut- enheter (l/O) för sampling och styrning av externa processer. Dessutom så måste det finnas en global synkroniserad tidsbas, med en känd preci- sion ö, vilket innebär att två noder i systemet har lokala klockor som ald- rig skiljer sig åt mer än ö.

Uppfinningen kan användas i såväl enkla datorer som parallella och dis- tribuerade system. Figur 1 visar de inspelningar som behövs för en en- 10 15 20 25 30 35 524 799 s skild nod. För system med flera noder krävs motsvarande inspelningar för varje nod.

Mjukvaran som exekveras på det distribuerade systemet består av en uppsättning av samtidiga processer och avbrottsrutiner som kommunice- rar genom att skicka meddelanden eller via delat minne. Processer och avbrott kan ha funktionella och tidsmässiga sidoeffekter på grund av fö- regripning, meddelandeöverföring och delat minne, dvs. de kan oavsikt- ligt påverka varandra.

Figur 1 visar en process 1 som är en av flera processer som kan exekve- ras i ett realtidssystem. Processen kommunicerar med en OS kärna 3 genom ett första gränssnitt IF1. Kommunikationen över lF1 innefattar händelser såsom aktivering och terminering av processen, systemanrop, föregripning och avbrottsträffar. Kärnan förutsätts vara en exekverande realtidskärna som kan, men behöver inte, stödja föregripande schema- läggning.

Processen 1 kan även kommunicera med en eller flera externa processer 5, via ett andra gränssnitt lF2. Över detta andra gränssnitt |F2 kan exter- na data mottas av processen och utdata kan skickas till den externa pro- cessen 5.

I association med kärnan 3 och/eller processen 1 finns det en inspel- ningsenhet 7 som spelar in kommunikationen över gränssnitten lF1 och lF2, inklusive signifikanta systemhändelser, såsom de ovan nämnda och även accesser till realtidsklockan.

För varje tillämpning bör signifikanta variabler identifieras, såsom till- ståndsvariabler och perifera indata, såsom läsningar av analog/digital- omvandlare eller händelser såsom accesser till den lokala klockan. Des- sa signifikanta variabler bör spelas in så att de kan återuppspelas off-line.

Signifikanta variabler som kan återskapas genom återexekvering av pro- grammet behöver inte spelas in, eftersom de kommer att vara tillgängliga under programexekveringen. l ett multiprocessrealtidssystem så måste, förutom de olika sorterna av ovan listade variabler, dessutom systemets kontrollflöde spelas in. Detta motsvarar väsentligen processbyten och 10 15 20 25 30 35 524 799 9 avbrottsstörning, dvs. överföring av kontroll från en process till en annan process, eller från en process till en avbrottshanteringsrutin och tillbaka.

Externa interaktioner |F2 och anropen till OS kärnan lFl måste enligt uppfinningen spelas in. Övervakningen bör vara tillräckligt detaljerad så att den exakta förekomsten av föregripanden och avbrottsstörningar kan avgöras, dvs. den bör spela in programräknarvärdena när händelserna uppstod. Alla inspelade händelser bör dessutom tidsstämplas i enlighet med den lokala realtidsklockan.

Inspelningen av meddelanden gör det möjligt att, för en nod i taget, lokalt áteruppspela interaktionen med andra noder i systemet utan att man be- höver återuppspela hela systemet samtidigt. Globalt synkroniserade tids- stämplar för alla händelser möjliggör debuggning av hela det distribuera- de realtidssystemet och även visualisering av alla inspelade och äterexe- kverade händelser i systemet. lnspelningsmekanismen måste även stödja inspelningar definierade av programmeraren, dvs. det bör finnas systemanrop för inspelning av l/O- operationer, lokalt tillstànd, access till realtidsklockan, mottagna medde- landen och accesser till delade data.

Tre typer av inspelningsenheter kan användas: Icke-inkräktande hàrdvaruinspelare använder, t.ex. hàrdvaru, i- kretsenrealiserade emulatorer (lCE) med dubbelportsminne. Den här ty- pen av historieinspelare kräver ingen instrumentering av målsystemet, om den i-kretsenrealiserade emulatorn har realtidsoperativsystems- (RTOS)- medvetenhet eller avbrottsservicerutinsmedvetenhet. Flertalet kommersiella ICE-produkter erbjuder detta särdrag, t.ex. de som mark- nadsförs av Lauterbach och AMC. Med en sådan ICE är det möjligt att observera tillståndet hos RTOS genom övervakning av förändringarna i datastrukturer hos RTOS via dubbelportminnet. Detta kan även utföras för enklare händelsetriggadesystem genom att observera inträffade av- brott och data kan inspelas om dess plats i minnet är känd. De flesta kompilatorer och länkare kan på begäran generera adresser till variabler om de tillfrågas. Dessutom är perifera indata/utdata oftast minnesavbil- dad och specificerad i länkkonfigureringsscripter. 10 15 20 25 30 35 524 799 10 lcke-inkräktande hårdvaruinspelningsmedel är icke-inkräktande eftersom den idealt inte kommer att stjäla några CPU-cykler eller minne från målet.

Hybrid hårdvaru-/mjukvaruinspelningsmedel har hårdvarustöd och ett minimum av målmjukvaruinstrumentering. lvljukvaruprober skriver histo- riedata till specifika adresser och specifik hårdvara används för att samla historier, t.ex. genom att använda logikanalysatorer eller bussavlyssning.

Kommersiellt tillgängliga inspelningsmekanismer innefattar de från Agi- lent, Lauterbach, VisionlCE och Microtek.

Hybridinspelningsmedel kan även vara icke-inkräktande om alla datama- nipulationer och tillstånd reflekteras i systemets externa minne, och RTOS- och datamedvetenhet tillhandahålls. l verkligheten har emellertid många mikrokontroller och CPU:er on-chip cache- och primärminnen, vilket innebär att eventuella förändringar i tillstånd eller data hos systemet inte nödvändigtvis återspeglas i det externa minnet. Därför är det nöd- vändigt att instrumentera tillämpningen och operativsystemet så att till- lämpningens dataflöde och kontrollflödet för avbrott och processbyten spelas in och lagras i externt minne, vilket temporärt kringgår chache- minnet och on-chip minnet.

Eftersom all instrumenteringskod konsumerar CPU-cykler så måste den lämnas i målsystemet för att eliminera probeffekten. Observera att det inte är nödvändigt att spara data såsom meddelanden som skickas mel- lan processer, eftersom dessa överföringar kan återexekveras off-line. En extern historiker, som kommer att beskrivas nedan i närmare detalj, sam- lar sedan alla förändringar i denna buffert och konstruerar en historia.

Hybridinspelningsmedlet är mindre kostsamt än lCE:n, men båda typerna har skalningsproblem för multiprocessorsystem och distribuerade sy- stem.

Mjukvaruinspelningsmedel har ett instrumenterat operativsystem och till- lämpningsmjukvara, där historier sparas lokalt i cirkulära minnesbuffertar, typiskt av programmerbar storlek. Denna typ av inspelningsmedel är ock- så inkräktande, på så sätt att den konsumerar CPU-cykler för lagring av händelser och genom att den också behöver minne för lagring av data- 10 15 20 25 30 35 524 799 11 och kontrollflöden. En fördel med mjukvaruvinklingen är att den överva- kar systemet från "insidan", vilket innebär att on-chip minnen och cha- cheminnen inte utgör något hinder.

Genom att lämna proberna i målsystemet så undviks probeffekten, dvs. det som exekveras under test och debuggning kommer även att exekve- ras i det levererade systemet. Det interna historielagret består av en cy- klisk array av buffertar med programmerbar längd. Under testning kan innehållet i de cykliska buffertarna periodiskt laddas upp till historikern för ihopsamling av längre historier utan att avbryta tillämpningen, tex. genom användning av en lågprioriterad process. Det är även möjligt att exekvera systemet tills det kraschar och sedan ladda upp den lagrade historien i målet till historikern.

Mjukvaruinspelningsmedlet möjliggör, till skillnad från hårdvaru- och hy- bridinspelningsmedlen beskrivna ovan, diagnos och debuggning av sy- stemet efter leverans. Med andra ord har den svart-låde-funktionalitet, såsom allmänt känt från flygplan. Detta innebär att ett deterministiskt återskapande av exakt vad som hände vid ett rapporterat fel i princip är möjligt.

Mjukvarubaserade inspelningsmekanismer erbjuder dessutom en lösning som år skalbar till multiprocessor eller distribuerade system till en lägre kostnad än hårdvaru- och hybridinspelningsmedlet, eftersom den enda extra kostnaden är minne och ett fåtal CPU-cykler.

I kontrast till vad som föreslagits av Thane och Hansson så kan uppfin- ningen àterexekvera historier med användning av ett normalt RTOS, dvs. ingen speciell off-lineversion av RTOS krävs. Detta åstadkoms genom inskjutning av brytpunkter vid punkter i programmet där kontrollflödet av den inspelade exekveringen ändras (t.ex. vid processbyten, avbrottsin- träffanden och systemanrop). Kod som emulerar det förändrade kontroll- flödet adderas till brytpunkterna. Detta beskrivs mer i detalj nedan.

Figur 2 visar konfigurationen som används vid debuggning enligt en utfö- ringsform av uppfinningen. Processen 1 kommunicerar nu över gränssnit- tet IF1' med en exekverande off-line kärna 3”. Off-line kärnan 3' kan si- 10 15 20 25 30 35 524 799 12 mulera några av de processer som utförts av den exekverande kärnan 3 i figur 1, men realtidsklockan och schemaläggningsfunktionerna behövs inte. Vilka processer som behövs och hur de kan utföras kommer att dis- kuteras nedan. Processen 1 kommunicerar även med en debugger 9 via ett gränssnitt lF2', för att simulera kommunikationen som normalt skulle ske med den externa processen 5 i figur 1. lnspelaren 7 använder i detta fall data som inspelats i konfigurationen i figur 1 för att styra off-line kär- nan 3' och kommunikationen över gränssnittet lF2”.

Off-line kärnan 3' kan, med stöd av debuggern 9, återuppspela alla signi- fikanta systemhändelser som spelats in av inspelningsanordningen 7.

Detta inkluderar start av processer i den inspelade ordningen och utfö- rande av processbyten och upprepande av avbrottsstörningar vid de in- spelade programräknarvärdena. Återuppspelningsschemat reproducerar även accesser till den lokala klockan, l/O-funktioner över lF2 och acces- ser till delade data, genom att tillhandahålla inspelade värden.

Debuggern 9, som kan vara en konventionell debugger av känd typ, kommunicerar även med off-line kärnan 32 En alternativ utföringsform skiljer sig från den i figur 2 genom att ingen off-lineversion av kärnan används. I detta fall kan standarddebuggrar, inklusive ICE, logikanalysatorer och instruktionssimulatorer användas.

Dessutom kan den verkliga hårdvaran användas tillsammans med fjärr- debuggning, som ibland kallas bakgrundsdebuggning. Det enda kravet för detta är att brytpunkterna kan stoppas in och att tillstàndstransforme- rande kod kan exekveras vid brytpunkterna.

Debuggern i figur 2 är realiserad i mjukvara. Alternativt kan debuggern vara realiserad i hårdvara. l detta fall utgörs debuggern av en i-kretsen realiserad emulator försedd med nödvändig mjukvara. Hårdvaran möjlig- gör inspelning, definition av brytpunktsmarkörer, bekräftelse på exekve- ring av brytpunkter, samt möjligheten att förändra systemtillstàndet för återuppspelning och styrning av exekveringen av mälsystemet. 10 15 20 25 30 35 524 799 13 Alternativt kan fjärrdebuggning användas. Detta innebär att debugg- ningsprogrammet körs på en separat dator. Detta kallas även Back- ground Mode Debugging (BMD). l ett multiprocessrealtidssystem måste, utöver vad som beskrivits ovan, processintersekvenseringshändelser spelas in. Figur 3 visar ett förenklat exempel på processintersekvensering i ett multiprocessrealtidssystem.

Den horisontella axeln är en tidsaxel.

Händelser spelas in enligt följande: Process A startar vid tid t=O.

Process A föregrips av process B vid t=4 vid programräknarvärdet PC=x.

Avbrott I startar vid t=7 och föregriper process B vid programräknarvärdet PC=y Avbrott I avslutas vid t=9.

Process B återupptas vid t=9 med PC=y.

Process B avslutas vid t=10. process A återupptas vid t=1O med PC=x.

Process A avslutas vid t=11.

Process C startas vid t=11.

Process C avslutas vid t=16 I debuggningsystemet enligt uppfinningen så sparas tiden varje gång ett processbyte utförs. Dessutom, om en föregripning inträffar, t.ex. vid t=4 och t=7, lagras även programräknarvärdet. Om en extern variabel inma- tas så måste värdet hos denna variabel lagras.

När inspelningen är genomförd är historien upprättad, för efterföljande återexekvering i debuggern. För att möjliggöra en trogen återexekvering i debuggern så sorterar historikern först händelserna i den tidsordning de inträffat och skapar en tidslinje. Om systemet är ett mutiprocessor- eller ett distribuerat realtidssystem konstruerar historikern synkroniserade pa- rallella tidslinjer baserade på inspelningarna vid varje nod. Tidslinjen för kontrollflödet representeras av en sekvens av villkorliga brytpunkter, så att en brytpunkt sätts för varje programräknarvärde där en kontrollflödes- händelse inträffat, bevakad av villkoret för den inspelade väsentligen uni- 10 15 20 25 30 35 524 799 14 ka markören. Utformningen av den väsentligen unika markören kommer att diskuteras nedan.

För varje brytpunkt exekveras ett makro (eller program) som sätter till- ståndet i målsystemet tili samma tillstånd som det var i precis före pro- cessbytet under den ursprungliga exekveringen. Detta innefattar uppda- tering av minnen och register, och inmatningen externa variabelvärden.

De externa variabelvärdena måste hämtas från de tidigare lagrade vär- dena.

Till exempel, när en högprioriterad process föregriper en annan process så kan makrot eller programmet innefatta följande handlingar: o Lägg processen som skall exekveras härnäst vid brytpunkten i be- redskapskön. Säkerställ att den har den högsta prioriteten i kön. o Generera ett tidsavbrott eller motsvarande för att aktivera RTOS schemaläggaren så att den utför processbytet.

Exakt hur detta kan ske i ett specifikt RTOS beskrivs nedan.

På liknande sätt sammanställs en tidslinje för dataflödet. Om ett hårdva- rubaserat inspelningsmedel används kan databrytpunkter tilldelas, dvs. brytpunkter som triggas när specifika adresser hämtas. Till exempel, när en variabel eller indata/utdata-enhet läses så kan innehållet på den häm- tade adressen återskapas från inspelningen innan värdet verkligen läses av tillämpningen, genom exekvering av ett program som är associerat till databrytpunkten.

För hybrid- och mjukvaruinspelare kan övervakningsomslag (monitor wrappers) användas: Monitor(&var,output,sizeof(var_type));.

Under inspelningen så returnerar övervakningsomslagen det specifika dataelementet var. Under âteruppspelning sker det omvända, dvs. data- elementet var tilldelas värdet för det utdata som inspelats. lO 15 20 25 30 35 524 799 15 Om den fullständiga markören är sann så är brytpunktsvillkoret uppfyllt.

Makrot eller programmet som är associerat till brytpunkten exekveras för att exekvera en av inspelningen bestämd systemhändelse.

Figur 4, 5 och 6 visar schematiskt den del av en exekverande kärna som används för att styra vilken process som skall exekveras vid varje given tidpunkt, dvs. för att reproducera processintersekvensering såsom den illustrerad i figur 3.

Program som inte skall exekveras vid en given tidpunkt hålls i ett vänte- område 21 av kärnan. Program som är redo för exekvering vid samma tidpunkt hålls i ett beredskapsområde 23. En tabell 25 lagrar information om varje program. Den vänstra kolumnen i tabellen 25 innehåller pro- gramnamnet, i detta fall A, B och C. l\/littenkolumnen innehåller pro- grammens periodtider. I detta fall 10, 15 och 27 sekunder, för program- men A, B, respektive C. Den högra kolumnen innehåller en räknare som visar återstående tid innan programmet överförs från vänteområdet 21 till beredskapsområdet 23. Till exempel i ett on-line system, kan räknaren räknas ned av operativsystemet, och när en räknare ges värdet O så överförs det aktuella programmet till beredskapsområdet 23. l det generella fallet enligt uppfinningen, är debuggningsystemet i stånd att snappa upp operativsystemets funktion för att styra vilken process som skall exekveras härnäst. Hur detta uppnås beror på hur funktionen är realiserad i operativsystemet.

I detta exempel, där det antas att en off-line kärna används, är nedräk- ningsfunktionen deaktiverad i off-line kärnan. Istället sätts räknaren direkt till O, när systemet under återuppspelningen fastställer att programmet skall exekveras härnäst. Detta kan utföras, till exempel för program B, när det bestämts att B ska startas vi nästa brytpunkt. Således, enligt upp- finningen, bibehålls kärnans funktion för hantering av programmens till- stånd, men mekanismen för att ändra tillståndet ändras för att möjliggöra förändringar vid vilken önskad tidpunkt som helst. l figur 4 körs programmet A, samtidigt som B och C är i väntetillstånd. I figur 5 har programmet B överförts till beredskapstillståndet. l detta ex- 10 15 20 25 30 35 524 239 empel har programmet B högre prioritet än programmet A, varför pro- grammet A föregrips, dvs. programmet B överförs till ett exekveringstill- stånd och programmet A överförs till beredskapstillståndet och kan inte startas igen förrän programmet B har avslutats. Situationen efter före- gripning visas ifigur 6.

I den ovan beskrivna kända lösningen är det inspelade värdet för identifi- ering av en brytpunkt det motsvarande programräknarvärdet. Detta fun- gerar endast om ett givet programräknarvärde enbart inträffar en gång under programmets exekvering. I åtminstone tre fall uppfylls inte detta: om programmet innehåller loopar, underrutiner eller rekursiva funktioner. l dessa fall kan samma instruktioner komma att exekvera flera gånger såsom diskuterats i inledningen. Därför kan programräknar värden (PC) återanvändas i loopar, underrutiner och rekursiva funktioner. På grund av detta och på grund av den grova och oförutsägbara upplösningen hos reguljära tidtagare hos CPU:er är det nödvändigt att definiera en unik, eller tillräckligt unik, markör. l enlighet med uppfinningen så lagras därför en markör för varje bryt- punkt. Markören består allmänt av den variabla tiden (t), programräkna- ren (PC) och åtminstone en ytterligare väsentligen unik markör.

Om målsystemet stödjer instruktionsräknare (lC) kan den väsentligen unika markören definieras av tupeln . lnstruktionsräknaren gör det möjligt att åtskilja olika loopiterationer och funktionsanrop. Den vari- abla tiden, t, arbetar med en grövre skala och underlättar åtskillnad mel- lan inkarnationer av samma process, som kan vara fallet för periodiska processer.

Cykelräknare (CC) är vanligare i moderna mikroprocessorer än instruktionsräknare men har nackdelen att de är oförutsägbara under återuppspelningen på grund av icke-reproducerbart beteende hos ca- cheminnen och pipelines. Därför är de inte möjliga att använda som uni- ka markörer.

Ett alternativ är att använda mjukvarubaserade instruktionsräknare (SlC) som räknar bakåtgrenar och underrutinanrop i maskinkoden. För att den- 10 15 20 25 30 35 524 799 17 na lösning skall fungera så måste emellertid kompilatortillverkaren erbju- da detta särdrag eller speciella målverktyg som kan söka igenom ma- skinkoden och instrumentera alla bakåtgrenar och underrutinanrop. Detta sätt påverkar även prestandan, eftersom den vanligen allokerar ett eller flera CPU-register till instruktionsräknaren och därför minskar möjligheten till kompilatoroptimeringar.

Mer lämpligt är att använda en registerchecksumma (CHKSUM) som den väsentligen unika markören, varvid nämnda registerchecksumma är summan av innehållet i samtliga register vid brytpunktstillfället dividerat med antalet register.

Alternativt så kan en checksumma från användarstacken beräknas, t.ex. som definierad av omfattningen av den för närvarande exekverade funk- fionen.

Alternativt kan stackpekaren (SP) användas, vilket underlättar särskilj- ning mellan funktionsanrop i samband med underrutin- eller rekursiva anrop.

I en föredragen utföringsform kan både registerchecksumman och stack- pekaren användas tillsammans så att markören definieras av tupeln PC, SP, CHKSUM>. Denna kombination är tillräckligt unik, eftersom de flesta kompilatorer strävar efter att lägga loopräknare etc. i register för att optimera exekveringstiden. Ett krav för terminerande processer är dock att alla register initialiseras till noll när en process aktiveras. För icke- terminerande processer där kontrollflödet begränsas av en oändlig loop och blockerande systemanrop, krävs att processen periodiskt återställer sina register. En terminerande process motsvarar ett funktionsanrop, vil- ket termineras genom returnering av det minnesutrymme som den har använt under exekvering. Därför har en terminerande process ingen kontext mellan terminering och nästa anrop. En icke-terminerande pro- cess har alltid en kontext, motsvarande ett funktionsanrop som aldrig av- slutas. För icke-terminerande processer blir därför registrena orena efter en tid. 10 15 20 25 30 35 524 799 18 Givet en inspelad historia så måste en initial startpunkt hittas, dvs. ett tillstånd från vilket ett återuppspelningstillfälle kan startas. Det finns en mängd krav på ett sådant tillstånd, flera av dessa beror på systemarkitek- turen. Om systemet använder meddelandeöverföring så måste det globa- la starttillståndet vara överföringstomt, dvs. inget meddelande får vara under överföring, när återexekveringen startas. Om ett meddelande kan vara under överföring när återuppspelningstillfället startas så måste alla meddelanden som skickas mellan noder spelas in. För varje multipro- cessnod i systemet måste, om det lokala tillståndet kan ha föregripna el- ler exekverande processer, innehållet i sådana processer spelas in.

Den föredragna tekniken om registerchecksummemarkörer används är, enligt uppfinningen, att konstruera systemet så att det periodiskt når en punkt, kallad en sysslolös punkt, i exekveringen där ingen process är fö- regripen eller exekverande och där inget meddelande är under överfö- ring. Betrakta ett system där alla processer är av terminerande beskaf- fenhet, dvs. de anropas av RTOS kärnan som om de vore underrutiner, och när de avslutas så återlämnar de kontrollen till kärnan. Vid en sysslo- lös punkt vet vi att nästa process som startar sin exekvering kommer att befinna sig i ett definierat tillstånd, vanligen med alla CPU-register satta till O. Det enda som behöver göras, utöver att tillhandahålla korrekta ex- terna indata och meddelanden, är att tillhandahålla processen med kor- rekta värden på de globala och statiska variabler som den använder.

Om systemet har en icke-terminerande processmodell så kan process- styrningsflödet transformeras till en ekvivalent terminerande process. Till exempel representerar nedanstående kod en icke terminerande process i ett typiskt realtidssystem: Medan (FÖREVIGT) { Tillståndsvariabler; Vänta(signal); } Genom en enkel modifiering kan koden omformas till en ekvivalent termi- nerande process genom att flytta de lokala variablerna till ett separat block, eller företrädesvis till en separat funktion, efter vänta()- systemanropet, och således tilltvinga inspelning av tillståndsvariablerna 10 15 20 25 30 35 . - - 524 799 19 när de av-allokeras när de lämnar blocket. Följaktligen krävs en återställ- ning av tillstàndsvariablerna, precis som fallet skulle vara för termineran- de process. l detta fall utgörs återställningen av återställning av instruk- tionsräknaren eller processor-register. Återställningen av processor- registren är nödvändigt för att bortta skadligt registerinnehàll från föregå- ende beräkningar. Koden nedan är ett exempel pà resultatet av en om- formad version av koden ovan: Medan(FÖREVlGT){ Återställ_umarkör(); vänta(SlGNAL); anropa { tillståndsvariabler; återställ(tillstàndsvariabler); spara(ti|lståndsvariabler); } } eller alternativt l\/ledan(FÖREVlGT){ {tillståndsvariabler; vänta(signal); tillståndsvariabler= f(tillståndsvarlabler); } àterställ= umarkör(); } Nackdelen med metoden ovan är att den belastar systemutvecklaren el- ler analysverktyg med att låta dem identifiera vilken tillståndsinformation som behöver spelas in under exekveringen. Å andra sidan, om övervak- ningen i mjukvaruinstrumenterade system görs på rätt sätt, så är mer- kostnaden i processer och minnesutnyttjande minimal.

Om en användarstackchecksummebaserad markör används kan ovan- stående metod elimineras, eftersom ingen kodomformning behövs. Re- gisterkontamineringen rensas varje gång en funktion anropas, av kompi- 10 15 20 25 30 - e ' 524 799 = 20 E': '- .- latorgenererad kod. En annan fördel är att denna markör kan inkludera Ioopvariabler som lagras på stacken. Detta är således den föredragna utföringsformen av uppfinningen. Nackdelen med registerchecksumme- metoden är att den är beräkningsmässigt mer krävande.

Alternativt kan startpunkten för återuppspelningstillfället väljas när syste- met startas. I detta tillstånd är all statisk systeminformation känd, och återuppspelningstillfället kan startas med variablerna satta till sina ur- sprungsvärden. En nackdel med denna lösning är att den kräver en väl- digt stor inspelningsbuffert. Dessutom kan återuppspelningen av system- beteendet fram till en krasch vara mycket tidsödande om systemet har exekverat i flera dagar, eller tom månader, innan kraschen. Detta skulle kunna undvikas med en off-line-ögonblicksbilds-metod som under ett åte- ruppspelningstillfälle periodiskt sparar systemtillstàndet i minnet, tillgäng- ligt för hämtning under återexekvering. Detta skulle göra det möjligt att återuppspela tillfället en gång från början och ta ögonblicksbilder under exekveringens gång. l efterföljande exekveringar kan var och en av des- sa ögonblicksbilder användas som en utgångspunkt för återuppspelning.

En annan alternativ metod för att hitta uppspelningens startpunkter är att periodiskt ta ögonblicksbilder av systemtillstàndet under körningen. Sy- stemtillståndet skulle kunna definieras, till exempel av RTOS köer (be- redskaps, exekverande, blockerad etc.) och processernas kontext. Ögonblicksbufferten kommer då att tillhandahålla ett antal kända system- tillstånd från vilka ett uppspelningstillfälle kan startas. Fördelen med detta förfarande är att det räcker med inspelning av en relativt kort historia.

Rent praktiskt, för att kunna garantera att historien innehåller en giltig startpunkt så måste historien vara tillräckligt lång för att omfatta åtmin- stone en ögonblicksbild. Detta garanterar dock bara förekomsten av en giltig startpunkt och inte att felorsaken finns med. Periodiska dumpningar av hela systemtillstånd kommer dessutom att kräva avsevärd exekve- ringstid, vilket kan vara oacceptabelt för många realtidssystem.

Claims (9)

10 15 20 25 30 35 524 799 21 PATENTKRAV

1. Ett förfarande för debuggning av enkel- och multiprocessreal- tidssystem som exekverar på en enkelprocessor, en multiprocessor eller ett distribuerat system, och innefattar stegen: o exekvering av ett datorsystem som innefattar den programkod som skall debuggas o inspelning av alla signifikanta händelser under exekveringen av systemet o upprättande av en historia genom analysering och korrelering av de inspelade händelserna och insättning av brytpunkter vid varje signifikant händelse, varvid varje brytpunkt i programmet definieras av en brytpunktsidentifierare som innefattar en väsentligen unik markör, o återuppspelning av historien i en debugger som stödjer brytpunkter och makron, ändring av systemets tillstånd vid programpositioner där brytpunkter har insatts för att emulera den inspelade exekve- nngen, kännetecknat av att den åtminstone en väsentligen unika markören inne- fattar en checksumma.

2. Ett förfarande enligt patentkravet 1, varvid brytpunktsidentifie- raren innefattar programräknaren och systemtiden, tillsammans med den väsentligen unika markören.

3. Ett förfarande enligt patentkravet 1 eller 2, varvid den åtmin- stone en väsentligen unika markören innefattar en checksumma som in- nefattar summan av innehållet i samtliga register.

4. Ett förfarande enligt patentkravet 1 eller 2, varvid den åtmin- stone en unika markören innefattar en checksumma som innefattar summan av innehållet i användarstacken, inkluderande t.ex. omfattning- en av den funktion som för närvarande exekveras.

5. Ett förfarande enligt något av föregående patentkrav, varvid den väsentligen unika markören innefattar en stackpekare. 10 15 20 25 30 . - - 524 7229

6. Ett förfarande enligt patentkravet 1 eller 2, varvid den väsent- ligen unika markören innefattar av en instruktionsräknare (IC).

7. Ett förfarande i enlighet med något av föregående patentkrav, innefattande steget exekvering av förändringsemulerande kod vid åtmin- stone en brytpunkt för att emulera den inspelade förändringen i program- flödet när den exekveras i systemet.

8. En datorprogramprodukt för användning vid debuggning av en programkod i ett datorsystem, varvid nämnda datorsystem innefattar o medel för inspelning av alla signifikanta händelser vid exekvering av systemet o medel för att addera en brytpunktsidentifierare för varje brytpunkt o medel för att upprätta en historia genom analysering och korrele- ring av de inspelade händelserna, varvid nämnda datorprogram är anordnat att förändra systemets tillstånd vid positioner i program- met som kräver debugging medan historien återuppspelas, varvid medlet för addering av en brytpunktsidentifierare är anordnat att addera en brytpunktsidentifierare som innefattar åtminstone en väsentligen unik markör, och att den ytterligare innefattar o medel för återexekvering av den upprättade historien o medel för att vidta av lämpliga åtgärder när en brytpunktshändelse inträffar för att säkra att historien troget återexekveras, och som kännetecknas av att den åtminstone en väsentligen unika mar- kören innefattar en checksumma.

9. En datorprogramprodukt enligt patentkravet 8, anordnad att återspela historien i det ursprungliga systemet, och som att medlet för återexekvering av historien som initieras vid klockslagsiniti- erade schemahändelser, systemanrop och avbrott, är anordnat att exekveras vid åtminstone en brytpunkt.