SE524799C2 - Debugging method for single or multi process real time systems, identifies significant event break off point with unique marker comprising check sum - Google Patents

Abstract

The unique marker used to identify break-off points in the significant events occurring when the computer system is executed comprises a check sum. The real time system is executed on a single processor, multi-processor or distributed system. The debugging method comprises the following steps: (a) executing a computer system provided with the program code to be debugged; (b) recording all the significant events which occur; (c) maintaining a history by analyzing and correlating the recorded events and creating break-off points for each significant event, each break-off point in the program being defined by an identifier comprising an essentially unique marker; and (d) playing back the history in a debugger (9) which supports break-off points and macro and changing the state of the system at program positions where the break-off points have been inserted in order to emulate the recorded execution.

Description

25 30 35 524 799 2 Distributed real-time systems add an additional level of complexity, as processes can then be executed simultaneously on different nodes, which makes faithful re-execution even more complicated.

Tai et al .: "Debugging Concurrent Ada Programs by Deterministic Execution", IEEE Transactions on Software Engineering, Vol. 17, No. 1, January 1991, presents a language-based approach to deterministic execution debugging of concurrent programs written in The method shown by Tai et al. involves defining synchronization sequences for a program to be debugged, a language-based playback tool then used to transform the program to be debugged into a slightly different program which can then be executed on a reproducible The transformation of the program involves inserting one or more control packets into the program to control the execution of the various sequences in the program.

Leblanc and Mellor-Crummy: "Debugging Parallel Programs with Instant Replay", lEEE Transactions on Computers, Vol. C-36, No. 4, April 1987, shows a procedure for debugging parallel programs. During program execution, the relative order between significant events as they occur is saved, but not the data associated with each event. Interactions between processes are modeled as operations on shared objects. Each process records the version number of each shared object it accesses. A partial order for the accesses to each object is recorded, so that the order between the processes that reads a certain version of an object does not need to be established. During playback of the program in an equivalent virtual machine environment, each process recalculates its output values and thus provides input data to other processes. As stated by the authors themselves, the method, which they call Instant Replay, is not suitable for real-time systems due to the difficulty of simulating equivalent virtual machines.

McDowell and Helmbold: Debugging Concurrent Programs, ACM Computing Surveys, Vol. 21, no. 4, December 1989, describes three general techniques for debugging concurrent programs. Methods to avoid the 1024 20 25 30 35 524 g99 probe effect, i.e. that the observation itself inevitably changes the behavior of the program is discussed. These include that the probes, i.e. the parts of the program used for debugging purposes, are permanently in place and the use of hardware "hooks". No procedure that works satisfactorily for real-time systems is proposed.

Thane and Hansson: "Using Deterministic Replay for Debugging of Distributed Real-Time Systems", in the 12th Euromicro Conference on Real-Time Systems, pp. 265-272, Stockholm, June 2000, IEEE Computer Society, proposes a system for debugging distributed real-time systems, which can also be used for less complicated real-time systems.

The system proposed by Thane and Hansson has three main functions: - recording of all significant events during program execution - establishing the story by analyzing and correlating the recorded events' - replaying the story by using a customized off-line version of the kernel .

The recorded events can be process changes, interruptions and interactions with external processes. The story is drawn up as a timeline that represents the recorded execution. Once the story timeline has been established, it is fed to an instruction level simulator where it can be replayed.

A debugging problem occurs when the same instruction is executed fl times. The same program counter value is then used for more years. an occasion during the execution of the program, so that the program counter is not a unique identifier of the time when an event occurred. This occurs e.g. when the program contains a loop that is executed a number of times depending on a set of conditions. The same thing happens if a recursive routine is used. The recursive routine calls itself a number of times, for example until a parameter reaches a certain value. In these cases, the same program counter value will reappear for each loop, or each time the recursive routine is called. Therefore, the program counter care itself cannot uniquely identify the point in the program execution where a process change or an interruption occurred. 10 15 20 25 30 35 524 7949 Thane and Hansson suggest in the article quoted above that you save all information stored by the kernel during context changes, as well as stack and program counter registers that relate to the task. This saved context is used as a unique marker for the program. A disadvantage of this type of unique marker is that it can be computationally demanding to calculate and / or that it requires considerable memory to be saved. In addition, it is not guaranteed to be unique in the strict sense. An alternative approach could be to use hardware or software instruction counters. Unfortunately, such calculators are not normally available. Adding special hardware will be costly and a software calculator will be computationally demanding.

Programs often include one or more instruction sequences that are used only for debugging purposes. During execution, these instructions are simply ignored. This introduces a difference between the debugging situation and the execution situation, which is an additional problem when debugging real-time systems. A program that includes such debugging instructions will take longer to execute in the debugging situation, thus changing the behavior of the program. This leads to a probe effect, ie. by observing the system, we inevitably change it. l Thane H et al. "Debugging using time machines; Replay your embedded systems history" Nov 2001, in the Real-time & embedded computing conference, Milan, describes what is presented in the preamble to claim 1. PURPOSE OF THE INVENTION One purpose of the invention is to enable debugging of computer systems from individual programs with interrupt to multiprocess and distributed real-time computer systems.

SUMMARY OF THE INVENTION This object is achieved with the present invention by a method for debugging single and multiprocess real-time systems executed on a single processor, multiprocessor or distributed system, and comprises the steps of executing a computer system as a computer system. includes the program code to be debugged o recording all significant events during the execution of the system o establishing a history by analyzing and correlating the recorded events, inserting a breakpoint at each significant event o reproducing the history in a debugger that supports breakpoints and macros, changing the state of the system at program positions where breakpoints have been inserted to emulate the executed execution, characterized in that each breakpoint in the program is defined by a breakpoint identifier comprising a substantially unique marker, which marker comprises a checksum. The object is also achieved by a computer program product for use in debugging a program code in a computer system, said computer system comprising means for recording all significant events when executing the system and means for adding a breakpoint identifier for each breakpoint and means for establishing a history by analyzing and correlating the recorded events, said computer program being arranged to change the state of the system at positions in the program which require debugging while the history is being replayed, and characterized in that the means for adding a breakpoint identifier is arranged to add a breakpoint identifier that includes at least one substantially unique marker that includes a checksum, and that it further includes o means for re-execution of the established history o means for taking appropriate action when a breakpoint event occurs to ensure that the history is faithfully re-executed.

By "substantially unique" is meant that the marker should have a shape that will serve as a unique identifier for virtually any situation that may occur. Preferably, the computer program product is arranged to replay the history of the original system, and is characterized in that the means for re-executing the history initiated at time-initiated schedule events, system calls and interruptions is arranged to execute at least a breaking point.

The invention enables debugging of multiprocess and distributed real-time computer systems that contain loops and recursive calls. The invention can utilize any standard debugger that supports breakpoints and insertion of macros at the breakpoints, not just the instruction level simulator mentioned by Thane and Hansson.

The debugging method according to the invention does not require a change of the program to be debugged.

The invention handles sequences of debugging commands when debugging programs executed in a real-time computer system.

The invention handles non-terminating and terminating programs in debugging real-time computer systems. In a preferred embodiment, the breakpoint identifiers include the program counter and the system time together with the substantially unique cursor.

Preferably, the substantially unique marker comprises one of the following or a combination thereof: ø a checksum comprising the sum of the contents of all registers and / or parts of the user stack. This solution has the advantage that the compiler does not need to be modified. Hardware or software instruction counters are not required. This makes the proposed solution relatively inexpensive while enabling better optimization of the executed program code compared to what would be possible with the use of software instruction calculators. o A stack pointer and / or instruction counter (IC). This enables the utilization of any available HW resources, which is advantageous over software solutions from a resource perspective. Preferably, the method comprises the step of executing change emulating code at at least one breakpoint to emulate the change in the program flow recorded during the execution of the system.

The method and software product of the invention enable modifications and additions to the code to add debugging instructions or test software fixes. The system behavior in response to changed input data or changed code can be examined.

BRIEF DESCRIPTION OF THE DRAWINGS In the following, the invention will be described in more detail only as an example and with reference to the accompanying drawings, in which Figure 1 illustrates a simple computer system in which the invention can be used.

Figure 2 shows the Configuration used in debugging in accordance with an embodiment of the invention Figure 3 shows a simplified example of a process interleaving in a multiprocess real-time system.

Figures 4, 5 and 6 schematically show the parts of an executing core which are used to determine which process is to be executed at any given time, i.e. to reproduce process sequencing such as that shown in Figure 3.

DETAILED DESCRIPTION OF EMBODIMENTS The invention can be used in a distributed system comprising a number of nodes. Each node is an independent computer element, with a central process unit (CPU), memory, network access, a local clock and input / output units (I / O) for sampling and control of external processes. In addition, there must be a globally synchronized time base, with a known precision island, which means that two nodes in the system have local clocks that never differ more than island.

The invention can be used in simple computers as well as parallel and distributed systems. Figure 1 shows the recordings needed for a single node. For systems with several nodes, corresponding recordings are required for each node.

The software executed on the distributed system consists of a set of simultaneous processes and interrupt routines that communicate by sending messages or via shared memory. Processes and interruptions can have functional and temporal side effects due to anticipation, message transmission and shared memory, ie. they can inadvertently affect each other.

Figure 1 shows a process 1 which is one of several processes that can be executed in a real-time system. The process communicates with an OS core 3 through a first interface IF1. Communication over lF1 includes events such as activation and termination of the process, system calls, anticipation and interrupt hits. The core is assumed to be an executive real-time core that can, but does not have to, support anticipatory scheduling.

The process 1 can also communicate with one or more external processes 5, via a second interface lF2. Via this second interface | F2, external data can be received by the process and output data can be sent to the external process 5.

In association with the core 3 and / or the process 1, there is a recording unit 7 which records the communication over the interfaces lF1 and lF2, including significant system events, such as those mentioned above, and also accesses to the real-time clock.

For each application, significant variables should be identified, such as state variables and peripheral inputs, such as readings from analogue / digital converters or events such as accesses to the local clock. These significant variables should be recorded so that they can be replayed off-line.

Significant variables that can be recreated by re-executing the program do not need to be recorded, as they will be available during program execution. In a multiprocess real-time system, in addition to the different types of variables listed above, the system's control flow must also be recorded. This essentially corresponds to process changes and interruption disturbance, i.e. transferring control from one process to another process, or from a process to an interrupt management routine and back.

External interactions | F2 and the calls to the OS core lF1 must be recorded according to the invention. The monitoring should be sufficiently detailed so that the exact presence of anticipations and interruptions can be determined, ie. it should record the program counter values when the events occurred. In addition, all recorded events should be timed in accordance with the local real-time clock.

The recording of messages makes it possible, for one node at a time, to locally replay the interaction with other nodes in the system without having to replay the entire system at the same time. Globally synchronized timestamps for all events enable debugging of the entire distributed real-time system and also visualization of all recorded and re-executed events in the system. The recording mechanism must also support recordings defined by the programmer, ie. there should be system calls for recording I / O operations, local state, access to the real-time clock, received messages and access to shared data.

Three types of recording devices can be used: Non-intrusive hardware recorders use, e.g. hardware, i-circuit realized emulators (lCE) with dual port memory. This type of history recorder does not require any instrumentation of the target system, if the i-circuit realized emulator has real-time operating system (RTOS) awareness or interrupt service routine awareness. Most commercial ICE products offer this feature, e.g. those marketed by Lauterbach and AMC. With such an ICE, it is possible to observe the state of RTOS by monitoring the changes in data structures of RTOS via the dual port memory. This can also be done for simpler event trigger systems by observing interruptions that have occurred and data can be recorded if its location in memory is known. Most compilers and linkers can generate addresses for variables on demand if requested. In addition, peripheral input / output is usually memory mapped and specified in link configuration scripts. Non-intrusive hardware recording means is non-intrusive as it will ideally not steal any CPU cycles or memory from the target.

Hybrid hardware / software recorders have hardware support and a minimum of target software instrumentation. Lvljukware probes write history data to specific addresses and specific hardware is used to collect stories, e.g. by using logic analyzers or bus listening.

Commercially available recording mechanisms include those from Agilent, Lauterbach, VisionlCE and Microtek.

Hybrid recorders can also be non-intrusive if all data manipulations and states are reflected in the system's external memory, and RTOS and data awareness are provided. In reality, however, many microcontrollers and CPUs have on-chip cache and primary memories, which means that any changes in the state or data of the system are not necessarily reflected in the external memory. Therefore, it is necessary to instrument the application and the operating system so that the data flow of the application and the control flow for interruptions and process changes are recorded and stored in external memory, which temporarily bypasses the cache memory and on-chip memory.

Since all instrumentation code consumes CPU cycles, it must be left in the target system to eliminate the probe effect. Note that it is not necessary to save data such as messages sent between processes, as these transfers can be re-executed off-line. An external historian, who will be described below in more detail, then collects all the changes in this buffer and constructs a history.

The hybrid recording medium is less expensive than the ICE, but both types have scaling problems for multiprocessor systems and distributed systems.

Software recorders have an instrumented operating system and application software, where stories are stored locally in circular memory buffers, typically of programmable size. This type of recording medium is also intrusive, in that it consumes CPU cycles for storing events and in that it also needs memory for storing data and control streams. An advantage of the software angle is that it monitors the system from the "inside", which means that on-chip memories and the chemistry memory do not constitute an obstacle.

By leaving the probes in the target system, the probe effect is avoided, ie. what is executed during testing and debugging will also be executed in the delivered system. The internal history layer consists of a cyclic array of buffers of programmable length. During testing, the contents of the cyclic buffers can be periodically uploaded to the historian for collection of longer stories without interrupting the application, e.g. through the use of a low-priority process. It is also possible to execute the system until it crashes and then upload the stored history in the target to the historian.

The software recorder, unlike the hardware and hybrid recorders described above, enables diagnosis and debugging of the system after delivery. In other words, it has black-box functionality, as is commonly known from aircraft. This means that a deterministic re-creation of exactly what happened in the event of a reported error is in principle possible.

Software-based recording mechanisms also offer a solution that is scalable to multiprocessor or distributed systems at a lower cost than the hardware and hybrid recording medium, as the only additional cost is memory and a few CPU cycles.

In contrast to what was proposed by Thane and Hansson, the invention can re-execute stories using a normal RTOS, ie. no special offline version of RTOS is required. This is achieved by inserting breakpoints at points in the program where the control flow of the recorded execution changes (eg during process changes, interrupt occurrences and system calls). Code that emulates the changed control flow is added to the breakpoints. This is described in more detail below.

Figure 2 shows the configuration used in debugging according to an embodiment of the invention. Process 1 now communicates over the IF1 'interface with an executive off-line core 3 ”. The off-line core 3 'can simulate some of the processes performed by the executing core 3 in Figure 1, but the real-time clock and scheduling functions are not needed. What processes are needed and how they can be performed will be discussed below. Process 1 also communicates with a debugger 9 via an interface lF2 ', to simulate the communication that would normally occur with the external process 5 in Figure 1. In this case, the recorder 7 uses data recorded in the configuration in Figure 1 to control the line core 3 'and the communication over the lF2 interface ”.

The off-line core 3 'can, with the support of the debugger 9, replay all significant system events recorded by the recording device 7.

This includes starting processes in the recorded order and performing process changes and repeating interrupt disturbances at the recorded program counter values. The replay schedule also reproduces accesses to the local clock, l / O functions over lF2 and accesses to shared data, by providing recorded values.

The debugger 9, which may be a conventional debugger of known type, also communicates with the off-line core 32. An alternative embodiment differs from that in Figure 2 in that no off-line version of the core is used. In this case, standard debuggers, including ICE, logic analyzers and instruction simulators can be used.

In addition, the real hardware can be used in conjunction with remote debugging, sometimes called background debugging. The only requirement for this is that the breakpoints can be plugged in and that the state transforming code can be executed at the breakpoints.

The debugger in figure 2 is realized in software. Alternatively, the debugger can be implemented in hardware. In this case, the debugger consists of an in-circuit realized emulator provided with the necessary software. The hardware enables recording, definition of breakpoint markers, confirmation of execution of breakpoints, and the ability to change the system state for playback and control of the execution of the target system. 10 15 20 25 30 35 524 799 13 Alternatively, remote debugging can be used. This means that the debugging program runs on a separate computer. This is also called Background Mode Debugging (BMD). In a multiprocess real-time system, in addition to what is described above, process sequencing events must be recorded. Figure 3 shows a simplified example of process interleaving in a multiprocess real-time system.

The horizontal axis is a time axis.

Events are recorded as follows: Process A starts at time t = 0.

Process A is preceded by process B at t = 4 at the program counter value PC = x.

Interrupt I starts at t = 7 and anticipates process B at the program counter value PC = y Interrupt I ends at t = 9.

Process B is resumed at t = 9 with PC = y.

Process B ends at t = 10. process A is resumed at t = 10 with PC = x.

Process A ends at t = 11.

Process C is started at t = 11.

Process C ends at t = 16 In the debugging system according to the invention, the time is saved each time a process change is performed. In addition, if an anticipation occurs, e.g. at t = 4 and t = 7, the program counter value is also stored. If an external variable is entered, the value of this variable must be stored.

When the recording is completed, the history is established, for subsequent re-execution in the debugger. To enable a faithful re-execution in the debugger, the historian first sorts the events in the chronological order in which they occurred and creates a timeline. If the system is a multiprocessor or distributed real-time system, the historian constructs synchronized parallel timelines based on the recordings at each node. The timeline for the control flow is represented by a sequence of conditional breakpoints, so that a breakpoint is set for each program counter value where a control flow event has occurred, monitored by the condition of the recorded substantially unique marker. The design of the essentially unique marker will be discussed below.

For each breakpoint, a macro (or program) is executed that sets the state of the target system to the same state as it was in just before the process change during the original execution. This includes updating memories and registers, and entering external variable values.

The external variable values must be retrieved from the previously stored values.

For example, when a high-priority process precedes another process, the macro or program may include the following actions: o Place the process to be executed next to the breakpoint in the standby queue. Make sure it has the highest priority in the queue. o Generate a timeout or equivalent to activate the RTOS scheduler to perform the process change.

Exactly how this can happen in a specific RTOS is described below.

In a similar way, a timeline for the data flow is compiled. If a hardware-based recording medium is used, data breakpoints can be assigned, ie. breakpoints that are triggered when specific addresses are retrieved. For example, when reading a variable or input / output device, the contents of the retrieved address can be recreated from the recording before the value is actually read by the application, by executing a program associated with the data breakpoint.

For hybrid and software recorders, monitor wrappers can be used: Monitor (& var, output, sizeof (var_type)) ;.

During recording, the monitoring cover returns the specific data element where. During replay, the reverse occurs, ie. the data element was assigned the value of the output that was recorded. 10 15 20 25 30 35 524 799 15 If the complete cursor is true, the breakpoint condition is met.

The macro or program associated with the breakpoint is executed to execute a system event determined by the recording.

Figures 4, 5 and 6 schematically show the part of an executing core which is used to control which process is to be executed at any given time, i.e. to reproduce process sequencing as illustrated in Figure 3.

Programs that are not to be executed at a given time are held in a waiting area 21 of the core. Programs that are ready for execution at the same time are held in a contingency area 23. A table 25 stores information about each program. The left column in Table 25 contains the program name, in this case A, B and C. The l / litten column contains the period times of the programs. In this case 10, 15 and 27 seconds, for programs A, B, and C, respectively. the counter can be counted down by the operating system, and when a counter is given the value 0, the current program is transferred to the standby area 23. In the general case of the invention, the debugging system is able to intercept the operation of the operating system to control which process is to be executed next. How this is achieved depends on how the function is realized in the operating system.

In this example, where it is assumed that an off-line core is used, the countdown function is deactivated in the off-line core. Instead, the counter is set directly to 0, when the system during playback determines that the program is to be executed next. This can be done, for example for program B, when it has been decided that B should be started at the next breakpoint. Thus, according to the invention, the function of the core for managing the state of the programs is maintained, but the mechanism for changing the state is changed to enable changes at any desired time. In Figure 4, the program A is run, at the same time as B and C are in the waiting state. In Figure 5, program B has been transferred to the standby state. In this example, program B has a higher priority than program A, which is why program A is anticipated, ie. program B is transferred to an execution state and program A is transferred to the standby state and cannot be restarted until program B has ended. The situation after the pre-trial is shown in Figure 6.

In the known solution described above, the recorded value for identifying a breakpoint is the corresponding program counter value. This only works if a given program counter value only occurs once during program execution. In at least three cases this is not fulfilled: if the program contains loops, subroutines or recursive functions. In these cases, the same instructions may be executed several times as discussed in the introduction. Therefore, program count values (PC) can be reused in loops, subroutines and recursive functions. Because of this and because of the rough and unpredictable resolution of regular timers of CPUs, it is necessary to define a unique, or sufficiently unique, marker. In accordance with the invention, therefore, a marker is stored for each breakpoint. The cursor generally consists of the variable time (t), the program counter (PC) and at least one further substantially unique cursor.

If the target system supports instruction counter (IC), the essentially unique cursor can be defined by the tuple. The instruction counter makes it possible to separate different loopiterations and function calls. The variable time, t, works on a coarser scale and facilitates distinction between incarnations of the same process, which may be the case for periodic processes.

Cycle counters (CCs) are more common in modern microprocessors than instructional counters but have the disadvantage that they are unpredictable during playback due to non-reproducible behavior of the cachemines and pipelines. Therefore, they are not possible to use as unique markers.

An alternative is to use software-based instruction counters (SlC) that count backward branches and subroutine calls in the machine code. For this solution to work, however, the compiler manufacturer must offer this feature or special targeting tool that can scan the machine code and instrument all backward branches and subroutine calls. This method also affects performance, as it usually allocates one or more CPU registers to the instruction counter and therefore reduces the possibility of compiler optimizations.

It is more appropriate to use a register check sum (CHKSUM) as the substantially unique marker, said register check sum being the sum of the contents of all registers at the time of breaking point divided by the number of registers.

Alternatively, a checksum from the user stack can be calculated, e.g. as defined by the scope of the currently executed function fi.

Alternatively, the stack pointer (SP) can be used, which facilitates the distinction between function calls in connection with subroutine or recursive calls.

In a preferred embodiment, both the register check sum and the stack pointer can be used together so that the cursor is defined by the tuple PC, SP, CHKSUM>. This combination is unique enough, as most compilers strive to put loop counters, etc. in registers to optimize the execution time. A requirement for terminating processes, however, is that all registers are initialized to zero when a process is activated. For non-terminating processes where the control flow is limited by an infinite loop and blocking system calls, the process is required to periodically restore its registers. A terminating process corresponds to a function call, which is terminated by returning the memory space it has used during execution. Therefore, a termination process has no context between termination and the next call. A non-terminating process always has a context, corresponding to a function call that never ends. For non-terminating processes, the registers therefore become unclean after a while. 10 15 20 25 30 35 524 799 18 Given a recorded story, an initial starting point must be found, ie. a state from which a replay can be started. There are a number of requirements for such a permit, several of which depend on the system architecture. If the system uses message transmission, the global start state must be transmission empty, ie. no message can be transmitted when the re-execution is started. If a message may be in transmission when the replay is started, all messages sent between nodes must be recorded. For each multi-process node in the system, if the local state can have anticipated or executing processes, the contents of such processes must be recorded.

The preferred technique for using register checksum markers is, according to the invention, to design the system so that it periodically reaches a point, called an idle point, in execution where no process is anticipated or executing and where no message is being transmitted. Consider a system where all processes are of a terminating nature, ie. they are called by the RTOS kernel as if they were subroutines, and when terminated they return control to the kernel. At an idle point, we know that the next process that starts its execution will be in a defined state, usually with all CPU registers set to 0. The only thing that needs to be done, in addition to providing correct external input data and messages , is to provide the process with the correct values of the global and static variables it uses.

If the system has a non-terminating process model, the process control flow can be transformed into an equivalent terminating process. For example, the code below represents a non-terminating process in a typical real-time system: While (PRESENT) {State variables; Wait (signal); } By a simple modification, the code can be transformed into an equivalent terminating process by moving the local variables to a separate block, or preferably to a separate function, after the wait () system call, thus forcing recording of the state variables 10 15 20 25 30 35. - - 524 799 19 when un-allocated when leaving the block. Consequently, a reset of the state variables is required, just as would be the case for the terminating process. In this case, the reset consists of resetting the instruction counter or processor register. Restoring the processor registers is necessary to remove malicious register contents from previous calculations. The code below is an example of the result of a redesigned version of the code above: While (PREFERRED) {Reset_marker (); wait (SlGNAL); call {state variables; reset (state variables); save (state variables); }} or alternatively l \ / ledan (PREFERRED) {{state variables; wait (signal); state variables = f (state variables); } reset = unmark (); } The disadvantage of the above method is that it burdens the system developer or analysis tool with letting them identify which state information needs to be recorded during execution. On the other hand, if the monitoring in software-instrumented systems is done correctly, the additional cost in processes and memory utilization is minimal.

If a user stack checksum-based marker is used, the above method can be eliminated, since no code transformation is required. The register contamination is cleared each time a function is called, by compiler 10 e - 524 799 = 20 E ': Another advantage is that this marker can include Ioop variables stored on the stack. This is thus the preferred embodiment of the invention. The disadvantage of the register check sum method is that it is computationally more demanding.

Alternatively, the start point of the replay can be selected when the system is started. In this state, all static system information is known, and the playback time can be started with the variables set to their original values. A disadvantage of this solution is that it requires a very large recording buffer. In addition, replaying system behavior up to a crash can be very time consuming if the system has been running for several days, or even months, before the crash. This could be avoided with an off-line snapshot method that periodically saves the system state in memory during a replay, available for retrieval during re-execution. This would allow you to replay the occasion once from the beginning and take snapshots during the execution. In subsequent executions, each of these snapshots can be used as a starting point for replay.

Another alternative method of finding the starting points of playback is to periodically take snapshots of the system state while driving. The system state could be defined, for example, by RTOS queues (standby, execution, blocked, etc.) and the context of the processes. The Instant Buffer will then provide a number of known system states from which a playback time can be started. The advantage of this procedure is that it is sufficient to record a relatively short story.

In practical terms, in order to guarantee that the story contains a valid starting point, the story must be long enough to include at least a snapshot. However, this only guarantees the presence of a valid starting point and not that the cause of the error is included. Periodic dumping of entire system permits will also require considerable execution time, which may be unacceptable for many real-time systems.

Claims (9)

10 15 20 25 30 35 524 799 21 PATENT REQUIREMENTS A method for debugging single and multiprocess real-time systems executing on a single processor, a multiprocessor or a distributed system, and comprising the steps of: o executing a computer system comprising the program code to be debugged o recording all significant events during execution of the system o establishing a history by analyzing and correlating the recorded events and inserting breakpoints at each significant event, each breakpoint in the program being defined by a breakpoint identifier that includes a substantially unique marker, o replaying the history in a debugger that supports breakpoints and macros, changing the state of the system at program positions where breakpoints have been inserted to emulate the recorded execution, characterized in that the at least one substantially unique cursor comprises a checksum. A method according to claim 1, wherein the breakpoint identifier comprises the program counter and the system time, together with the substantially unique cursor. A method according to claim 1 or 2, wherein the at least one substantially unique marker comprises a checksum comprising the sum of the contents of all registers. A method according to claim 1 or 2, wherein the at least one unique marker comprises a checksum comprising the sum of the contents of the user stack, including e.g. the scope of the function currently being executed. A method according to any one of the preceding claims, wherein the substantially unique marker comprises a stack pointer. 10 15 20 25 30. - - 524 7229 A method according to claim 1 or 2, wherein the substantially unique marker comprises of an instruction counter (IC). A method according to any one of the preceding claims, comprising the step of executing change emulation code at at least one breakpoint to emulate the recorded change in the program flow when executed in the system. A computer program product for use in debugging a program code in a computer system, said computer system comprising o means for recording all significant events at execution of the system o means for adding a break point identifier for each break point o means for establishing a history by analysis and correlating the recorded events, said computer program being arranged to change the state of the system at positions in the program requiring debugging while the playback is being played, the means for adding a breakpoint identifier being arranged to add a breakpoint identifier comprising at least one substantially unique marker, and that it further comprises means for re-execution of the established history and means for taking appropriate action when a breakpoint event occurs to ensure that the history is faithfully re-executed, and which is characterized in that it comprises at least one substantially unique marker. r a checksum. A computer program product according to claim 8, arranged to replay the history of the original system, and wherein the means for re-executing the history initiated at time-initiated schedule events, system calls and interruptions is arranged to be executed at at least one breakpoint.