KR100426308B1 - Trace replay system and method for deriving certificated application program - Google Patents

Abstract

The present invention relates to non-stop debugging of a multi-threaded program in a remote development environment for developing an information appliance program, and in particular, receives a trace redo command for redoing a trace from a user and collects the trace according to the trace redo command. After generating trace redo frame composed of virtual register and memory by using the logging information, it checks the state of the application through existing debugging command or redo dump command, and according to the trace dump command input from the user during trace redo process. Analyze trace dump data in trace redo frames to find and fix bugs in the application, and fix bugs to obtain certified applications. You can obtain an authentication program by debugging the program without losing the state of the program, such as saving the beam to a file and running it again after execution is complete.

In addition, by using various options of the trace dump command, the conversion status of a specific variable can be examined by processing time, so that the user can debug the desired part of the application.

Description

TRACE REPLAY SYSTEM AND METHOD FOR DERIVING CERTIFICATED APPLICATION PROGRAM

The present invention relates to non-stop debugging of a multi-threaded program in a remote development environment for developing an information appliance program. In particular, the present invention relates to an authenticated trace reexecution using logging data generated after debugging an application in which a trace point is set. A trace redo system and method for acquiring an application is provided.

In general, embedded real-time software development for information appliances uses an editing and compilation environment, debugging and monitoring environment on the host computer, and produces and downloads the system information code for the information appliances and executes it on the target board for monitoring and debugging.

In order to provide an effective test environment and debugging environment under such a remote development environment, a test program can be downloaded from a host computer and executed while debugging. It is important to provide an environment in which signals can be continuously collected and collected on the basis of them, and analyzed based on the execution after completion of execution.

Using monitoring tracepoints to monitor signals on hardware chips is the basic task of hardware debugging. Collecting signals in real time continuously from the work environment and viewing them visually will provide the basis for understanding the behavior of the system. At present, it is considered an important task of hardware debugging to observe the variable signal change by changing the input value at trace points using a tool such as Logic Analyzer to determine the hardware performance when hardware electronic board is present. And the ability to revisit based on the data collected using this tool is considered more important.

As with hardware debugging, it is important to implement real-time applications using data collected from monitoring trace points when debugging software in remote development environments. However, the conventional technique in the software field uses a very simple method in which a developer constructs a simple log file by inserting and executing a "printf" statement directly at a trace point, and then outputs the file manually and traces the program manually. Or, in a more advanced way, we use the monitoring API functions at the point of trace to track the execution of the program in real time using the resource monitor.

However, the method of inserting a printf statement directly into an application program or executing a tracepoint using special monitoring API code has to be performed by injecting test code directly into the source code. There is a risk of breaking the code, and in all cases of testing, there is an inefficiency of writing a test program by changing the number of source codes.

Simplifying the creation, testing, and debugging of these cumbersome test programs so that they can be efficiently performed is strongly required to increase software development productivity.

SUMMARY OF THE INVENTION An object of the present invention is to solve such a problem in the prior art, and by using a logging data generated after executing an application program with a trace point configured, a trace frame having a virtual register and a memory is reconfigured and executed again. It is intended to provide a trace redo system and method for acquiring an authenticated application that discovers and modifies.

In order to achieve the above object, the present invention, in the method for replaying the trace using the logging data generated by the target for trace debugging the application program according to the tracepoint and the debugging command from the host, the trace for re-executing the trace Resetting the virtual memory and register values by reading and analyzing the trace message information from the logging data by receiving the redo command, and generating a trace redo frame using the virtual memory and register values reset according to the trace redo command; Analyze the trace dump data in the trace redo frame according to the trace dump command input during the trace redo process, and use the trace dump data to find and fix bugs in the application to authenticate the application. And a step of obtaining a gram.

In addition, the present invention, in a system for re-executing a trace using the logging data generated after trace debugging an application program that the trace point is set according to the trace debugging command, by receiving and interpreting a trace redo command for re-executing a trace Calling function Set the virtual register and memory information using logging data according to the host sending through the function and the trace redo command received through the remote function call of the host, and virtually reproduce the execution of the application. Includes targets to find and fix bugs in the application through virtual repros.

1 is an explanatory diagram of a multi-task remote tracepoint debugging environment applied to the present invention;

2 is a configuration diagram of an embodiment of a software function block for trace point debugging according to the present invention;

3 is a flowchart illustrating a trace debugging process using a nonstop trace debugging and trace reproducing technique of an application program according to the present invention;

4 is a flow diagram illustrating an embodiment of a processing method according to a trace play command input according to the present invention;

5 is a flow diagram illustrating an embodiment of an execution initialization process of a host and a target according to the present invention;

6 is a flowchart illustrating a trace frame switching process of a host according to the present invention;

7 is a flowchart illustrating a process of storing user trace dump data of a host according to the present invention;

8 is a flowchart illustrating a trace dump instruction process according to the present invention;

9 is a flowchart illustrating a trace data logging process of a target according to the present invention;

10 is a flowchart illustrating a trace redo process of a target according to the present invention;

11 is a flow diagram illustrating a process of generating a "next" trace frame for trace reproduction of a target according to the present invention;

12 is a flow chart of processing a stop process for trace reproduction of a target according to the present invention;

13 is a flowchart illustrating a process of reading a trace dump of a target according to the present invention;

14 is a flowchart illustrating a process of reading a trace dump history of a target according to the present invention;

15 is a flowchart illustrating a process of generating a trace playback frame of a target according to the present invention;

FIG. 16 is a flowchart illustrating the trace frame generation process described with reference to FIG. 15 in detail.

FIG. 17 is a detailed flowchart illustrating a process of interpreting a "tr" message in FIG. 16.

<Description of the code | symbol about the principal part of drawing>

20: trace command input unit 21: trace message output unit

23: trace playback unit 24: host debugging agent

25: trace function 26: application program

27: target debugging command processing unit 28: trace triggering processing unit

29: trace frame processing unit 30: trace data storage unit

There may be a plurality of embodiments of the present invention, and a preferred embodiment will be described in detail below with reference to the accompanying drawings. Those skilled in the art will be able to better understand the objects, features and advantages of the present invention through this embodiment.

1 is a diagram illustrating a multi-task remote tracepoint debugging environment applied to the present invention. The host computer 10 has a cross compiler, a source code editor, a trace debugger, and a trace based on a Windows NT or LINUX operating system 11. It consists of an Esto ToolSet (12) with a regenerator, a breakpoint debugging agent, and a host debugging agent, and on the targetboard side, debugging instructions and traces from the host, based on the Qplus RTOS kernel (13) on an information-only target processor (14). It consists of a target debugging agent and a target trace agent for processing point commands, and an application program and trace functions controlled by the agents. The serial and Ethernet 15 physically connects the information-only target processor 14 and the host computer 10.

The present invention uses the data collected through the trace point trap in the multi-task remote trace point debugging environment to configure the virtual memory and virtual register values to create a real-time tracking frame (hereinafter referred to as trace frame), and through the trace frame It reproduces the execution state of an application and realizes a debugging technique to find bugs that occurred in the application while reproducing the execution state of the application.

2 is a block diagram of a software function block for trace point debugging according to the present invention.

The host side includes a trace command input unit 20, a trace message output unit 21, and a trace reproducing unit 23 for reproducing execution of an application program of a target system. It consists of a host debugging agent 24 for connecting the target system to a remote procedure call (RPC) function.

The target side includes a target debugging command processor 27 for processing in response to a trace point related command from a host, a trace triggering processor 28 for adding / removing a trace point to an actual application, and processing a trace trap, and an application program ( 26) Trace data storage unit 30 for storing logging information such as memory information and register information in the trace point trap when executed, and stored in the trace data storage unit 30 when the multi-threaded application program 26 is executed. It consists of a trace frame generation unit 29 and a trace function 25 that virtually reproduces the execution image in time order using the information.

The trace command input unit 20 receives and processes a command input such as a trace inputted by a user, trace playback, debugging, or program termination.

The trace message output unit 21 outputs the trace result of the target in real time according to the command input from the trace command input unit 20, and the trace reproducing unit 23 actually executes a function of the target of the trace and trace reproduction related commands. Let's do it.

The host debugging agent 24 transmits the command interpreted by the trace reproducing unit 23 to the target debugging command processing unit 27 through a remote function call, and the target debugging command processing unit 27 receives the remote function call from the host. The command is transmitted to the trace triggering processor 28.

The trace triggering processing unit 28 traces the application program 26 by driving the trace function 25 when a trap is generated at the trace point according to the command transmitted from the target debugging command processing unit 27.

The trace function 25 is driven by the trace triggering processing unit 28 at the trace point, the trace data storage unit 30 stores the trace event data when the trace trap is generated, and the trace frame generator 28 traces the trace. By using the data stored in the data storage unit 30 to simulate the execution of the application program 26, in other words, the trace frame generation unit 28 generates a virtual register and memory information to generate a new trace frame.

The developer analyzes the application to be tested nonstop, sets up the trace tag in the appropriate location with any editor, and creates a trace map file and user-defined trace function from the trace tag. The file generated after cross-compiling the trace map and the user-defined trace function is downloaded to the target.

Here, the user-defined trace function refers to a C language function to be called at the point of time when the set trace point is executed while the application program on which the trace point is set is executed. You can print the values of local or global variables, memory and registers, or stacks, message queues, semaphores, and so on. Writing this function is the same as writing a normal C language function.

The trace point is set in the application program 26 of the target through the trace command processor 20, the trace reproducing unit 23, the host debugging agent 24, and the trace triggering processor 28.

In the target, the trace point adding instruction obtained through the target debugging instruction processor 27 inserts the trace point directly into the application program 26 by the trace triggering processor 28.

The trace point trap is generated according to the execution of the application program 26 in which the trace point is inserted, and the trace triggering processor 28 performs the trace function 25 by the generated trap signal, and generates the data according to the execution result. The logging information is stored in the trace data storage unit 30.

After the application executes for a predetermined time (that is, after some amount of trace data logging information is performed to examine the execution state of the application), the trace frame generator 29 logs data stored in the trace data storage 30. The information is used to construct a new trace frame using the virtual register information and the memory information.

The target debugging command processing unit 27 obtained from the host debugging agent 24 transfers the playback command signal generated from the host trace reproducing unit 23 to the trace triggering processing unit 28, and inputted by the trace triggering processing unit 28. In response to the reproduction command signal, the trace frame generation unit 29 re-executes an application program virtually using a trace frame composed of virtual registers and memory information.

The trace play command consists of a "trace find start" command that constitutes a trace frame, a "trace find next" command that constitutes a next trace frame, and a "stop" to stop reproduction by generating a trace frame. trace find stop) "command, which consists of a" trace dump "command that dumps trace data for debugging after the trace frame is generated. In addition, debugging commands such as where and print which are used in general gdb can be used. This is possible because the target reproduces memory information and register information as if the actual application had been executed.

3 is a flowchart illustrating a trace debugging process using a nonstop trace debugging and trace reproducing technique of an application program according to the present invention.

The process of debugging nonstop traces of an application is divided into four steps.

The first step is to process the trace debugging command. The user inputs the user command and executes the commands so that the monitoring trace point can be set / released on the host computer, and the test program can be downloaded and executed (S201). ).

The second step is to turn on / off the monitoring trace point, which is the target trace point on / off step that directly inserts or restores undefined-exception code to the application from the target processor. (S202).

The third step is the execution of the application program and the execution of the user trace function call, which is a triggering processing step that actually triggers the trace function 25 as a trap occurs at the trace point while the application 26 is being executed (S203). ).

The fourth step is outputting and storing the trace message, and the trace message output unit 210 acquires and outputs a trace message acquired through the trace function 25 triggered (function call) at the trace point through the serial line. (S204).

The process of correcting an error and obtaining an authenticated application through a trace reproducing technique is largely composed of four steps.

The first step receives a trace redo command for redoing a trace from the user, and the second step generates a trace redo frame made of virtual registers and memory according to the trace redo command, and then applies an existing debug or redo dump command. The state of the program is checked (S205, S206).

The third step analyzes the trace dump data in the trace redo frame according to the trace dump command input from the user during the trace redo process, and finds and fixes the bug in the application. The fourth step fixes the bug and authenticates the authenticated application. To obtain (S207, S208).

4 is a flowchart illustrating an embodiment of a processing method according to a trace reproducing command input according to the present invention.

As shown therein, the trace command input unit 20 determines whether the trace reproducing command input by the user is “start”, “next” or “stop” (S301).

As a result of the determination of step 301, when the trace reproducing command input from the trace command input unit 20 is "start", the host and the target are initialized, and through the initialization, the trace reproducing unit 20 of the host and the trace frame generation unit of the target ( 29) are in the initial state (S302).

After the initialization step, the application program 26 actually executes the trace frame generator 29 on the target side, which receives the “start” command among the trace play commands, through the remote function call from the execution image information generated by the trace point debugging command. The virtual register and memory information is formed as in the case of the same, and the host frame information is configured on the host side based on the virtual register and memory information generated by the trace frame generation unit 29 (S303 and S304).

The target re-executes the trace by using the virtual execution image composed of the virtual register and memory information generated by the trace frame generator 29, and the host side reads the user trace dump data from the target and sets a predetermined storage space (for example, Hard disk) (S305).

Here, the host trace frame information includes program counter (PC) information, a specific stack position of the application program 26, and symbolic information on the stack.

As a result of the determination of step 301, when the trace reproducing command input from the trace command inputting unit 20 is “next”, the host may present the trace frame generating unit 29 of the target side through the target trace frame generating remote function call. Instructing to configure a trace frame corresponding to the next frame at the position, the trace frame generation unit 29 configures a trace frame corresponding to the next frame at the current position (S306, S307).

The host stores the user trace dump data transmitted from the host trace frame switching and the target on the hard disk (S306 and S307).

As a result of the determination of step 301, when the trace reproducing command input from the trace command inputting unit 20 is "stop", the host instructs the trace frame generation unit 29 of the target to stop trace reproducing through a remote function call. The trace frame generation unit 29 stops trace reproduction according to the obtained stop instruction (S309).

After step 309, the host initializes the host and the target after storing the user trace dump data transmitted from the target on the hard disk as in steps 302 and 305 (S310 and S311).

5 is a flowchart illustrating an embodiment of a process of initializing execution of a host and a target according to the present invention.

As shown therein, the host and the target require an initialization process for rerunning the trace, which starts by deleting all break information set for debugging of the application program 26 in the host (S401).

The host initializes the cache trace frame (that is, program counter information, sp information, register information, and symbolic value) used at the time of execution of the trace (S402), and the debugging event list used by the host debugging agent 24 in the existing debugging process. If you clear (S403), the target terminates the debugging threads used for debugging to make the execution state of the target the same as when the first debugger was executed (S404).

6 is a flowchart illustrating a trace frame switching process of a host according to the present invention.

As shown in the drawing, the trace frame switching process is performed by changing a trace frame (that is, a program counter, sp, symbol information) corresponding to a current program counter using register information of a target.

The host initializes all trace frame values to "0", requests the register information from the target using a remote function call, and changes the register value of the host using the register information transmitted from the target (S501 to S503).

The host reads the current program counter value from the changed register value and stores it in the global variable stop_pc, and converts the host's trace frame into a new one through the global variable (S504 and S505).

After step 505, the trace message output section 21 of the host prints information about the current trace frame (i.e., stack frame number, source line and location of the function, file name and function name, etc.) to the user. Shows the running state (S506).

7 is a flowchart illustrating a process of storing user trace dump data of a host according to the present invention.

As shown here, the host stores the file name and source line information and the target trace dump data corresponding to the current program counter in the user trace dump data file.

First, the host reads the program counter (pc) value from the register, compares the read program counter value with the symbol table, and obtains the file name and source line information to which the corresponding program counter belongs (S601, S602). The trace dump data is requested (S603), and the trace pump data received from the target is stored in the buffer (S604).

The host stores the trace pump data transmitted from the target in the buffer, and then examines the data stored in the buffer to determine whether there is a "NULL" or "EOF" (S605). If the test results in "NULL" or "EOF", the user trace dump data save step is terminated.

As a result of the judgment in step 605, when the result of the inspection of the data stored in the buffer does not come out "NULL" or "EOF", the host obtains the file name and source line information corresponding to the current program counter (S606), the file information, the line The source name and the trace dump data are stored in the user trace dump file (S607).

Steps 606 and 607 as described above are repeatedly performed until the buffer is "NULL" or "EOF".

8 is a flowchart illustrating a trace dump instruction process according to the present invention.

Prior to the description, the trace dump command optionally displays the trace history information of the target (that is, the program counter information, time information, source lines, and corresponding source information that has been tracked up to the current point in time order), or the user. List and display trace dump data history, or show user only the dump data collected in the current trace frame if no option is given.

The trace command input unit 20 of the host determines what the options of the trace dump command input by the user are (S701), and the option of the trace dump command inputted as a result of the determination of step 701 is the history information display option (“-t”). ”) Request the trace history information from the target (S702), and store the trace history information transmitted from the target in the buffer (S703).

The host examines the contents of the trace history information stored in the buffer to determine whether there are "EOF" messages and "NULL" in the contents of the buffer (S704). Terminates the process of processing the trace dump command when it exists.

As a result of the determination of step 704, the time and program counter information stored in the buffer are extracted when the contents of the buffer are “EOF” and “NULL”, and the source line value is calculated from the symbol table using the extracted program counter information. Afterwards (S705 and S706), the calculated information is output to the user through the trace message output unit 21 (S707).

The above steps 702 to 707 are repeated until the contents of the buffer become "EOF" messages and "NULL".

As a result of the determination in step 701, when the inputted option of the trace dump command is the option of displaying dump data in the order of execution (“-u”), the host reads the user trace dump data file and retrieves the user trace dump data. It is determined whether or not there is "EOF" in the search result data (S708, S709).

As a result of the determination in step 709, if there is no "EOF" in the data, the host repeats the process of outputting the contents of the read user trace dump data to the user through the trace message output unit 21 until "NULL" appears. It is performed by (S710).

The host terminates the trace dump command process if there is a "NULL" in the contents of the user trace dump data.

As a result of the determination in step 701, when there is no option of the input trace dump command (when reading user trace dump data corresponding to the current trace frame), the host requests the trace dump data by using a remote function call to the target ( S711), after storing the trace dump data transmitted from the target in the buffer, it is determined whether the buffer is "NULL" or "EOF" (S712, S713).

As a result of the determination in step 713, when the contents of the buffer in which the trace dump data is stored are not "NULL" or "EOF", the trace dump data stored in the buffer is output to the user through the trace message output unit 21 (S714, S715). Otherwise, terminate the trace dump command process.

Steps 711 to 714 are continued until the contents of the buffer become "NULL" or "EOF".

9 is a flowchart illustrating a trace data logging process of a target according to the present invention.

The trace data logging process of the target, as shown in Figure 9, during the application 26 running context ID (context id) setting request, register read / write, memory read / write, program pause, trace trap, program In response to an event such as termination, the trace log file is stored in a message of a preset format, and the stored message is used to re-execute after the execution of the application 26 (or after a certain time).

The target processes the event by receiving the event information requested by the user from the host. When the event requested by the user is a context ID setting request event (801), the context ID value is stored in the form of a 'hg <context id>' message (802). In case of register reading (803), all register values are stored in the form of 'g <register value>' message (804), and in case of register writing (805), register in the form of 'G <register value>' message. Store the values (806). In the case of a memory read event (807), the memory read value is stored in the form of 'm <address>, <number of bytes>: <memory value>' (808), and in the case of a memory write event (809), 'M < The memory write value is stored in the form of address>, B <byte number>: <memory value> '(810).

If the event requested by the user is a program pause event (811), the target is' T <signal #> <pc #>: <pc>; <fp #>: <fp>; <sp #>: <sp>; The message is stored in the form of <sec>. <usec> 'message (812), and in the case of the program termination event (815), the information is stored (816) in the form of' W <context id>, <signal #> '. In addition, in the case of a trace trap event (813) is stored in the form of a 'tr (...)' message (814), the information is stored in parentheses in accordance with the notation of the above-described events. For example, the storage of memory write events in the tracepoint trap is stored in the form of 'tr (M <address>, <byte number>: <memory value>)'. In addition to the existing events, the events in the tracepoint trap include 'tr (+)' and 'tr (*)' messages to indicate the start and end of the trace trap, and '' to indicate user trace dump data. tr (U <user dump data>) 'message.

10 is a flowchart illustrating a trace redo process of the target according to the present invention.

The trace re-execution process of the target starts with the process of changing the state of the target from the break debugging mode to the trace debugging mode as shown in FIG. 10 (S901).

The target converted to the trace debugging mode initializes the virtual register and the memory value to “0”, and the trace frame generator 29 reads the trace log file information stored in the trace data storage unit 30 and registers a new virtual memory and register. One reproduction trace frame having information is generated (S902, S903, S904), and the current trace frame state is stored in the trace data storage unit 30 as trace history data (S905).

11 is a flowchart illustrating a process of generating a "next" trace frame for trace reproduction of a target according to the present invention.

After the target initializes the trace dump data file of the target stored in the trace data storage 30 (1001), it determines whether the target state is in the trace debugging mode (S1002). As a result of the determination in step 1002, in the trace debugging mode, the trace frame generation unit 29 reads the trace log file stored in the trace data storage unit 30 to configure the virtual memory and register values corresponding to the next trace frame for reproduction. The current frame state is left as trace history data (S1004).

Trace history data is stored in the following message format depending on the breakpoint event, tracepoint event, or program termination event. Trace time information is obtained using "<sec>. <Usec>" information. Here, <sec> has a second unit value and <usec> has a micro second unit value.

12 is a flow chart of processing a stop process for trace reproduction of a target according to the present invention.

The stop process for trace reproduction of the target is that the target operates in response to the “stop” command among the trace reproduction commands.

The target receives the stop instruction among the trace play instructions, switches the trace debugging mode to the break debugging mode (1101), initializes the virtual register and memory values set by the trace frame generator 29 (1102), and After clearing the trace frame history (1103), the trace log file is closed (1104) to complete the trace replay function.

13 is a flowchart illustrating a process of reading a trace dump of a target according to the present invention.

The target performs a trace dump read in response to a trace dump data read command input from the host. The target reads the trace dump data file to determine whether the first trace dump data in the data file is accessible (1201). After opening the trace dump data file (1202) and reading the trace dump data (1203), if it is not the end of the file (1204), the current trace dump data is sent to the host (1206).

If it is the end of the trace dump file (1204), the trace dump data file is closed (1205), and then an "EOF" message is loaded into the trace dump data buffer and transmitted to the host (1206).

As above, opening the file from the first trace data and not opening the trace dump data from the second data sends the data one by one, moving only the file points of the trace dump data file for n trace dump data requests from the host. It is for.

14 is a flowchart illustrating a process of reading a trace dump history of a target according to the present invention.

The trace dump history read is a process in which a target received from a host reacts to a trace dump read command. The target reads a trace history file and determines that the first trace dump data stored in the file is accessible. The trace history file is opened (1302), the trace history is read (1303), and the current trace history is transmitted to the host (1306) if the file is not at the end (1304).

In this case, when the target is the end of the file (1304), the trace history file is closed (1305), and then an "EOF" message is loaded into the trace history buffer and transmitted to the host (1306).

15 is a flowchart illustrating a process of generating a trace playback frame of a target according to the present invention.

The trace frame generation unit 29 of the target reads the message for the trace log stored in the trace data storage unit 30 and determines whether the message size is larger than "0" (S1401). The determination result message of step 1401 If the size is smaller than "0", the trace play frame generation process is terminated.

As a result of the determination in step 1401, when the size of the message is larger than "0", the trace frame generation unit 29 interprets the read message and generates a new trace frame. It is to generate a register value (S1402).

The trace frame generator 29 determines whether the brake setting state and the brake setting number are "0" as a result of analyzing the message (S1403). As a result of the determination in step 1403, the brake setting state and the brake setting number is "0". If so, the trace frame generation process is terminated. Otherwise, the trace message is read from the trace log file (1401) and one trace frame generation (1402) is completed.

The virtual memory value and register value are created from the memory read / write message and register read / write message information of the trace log, and whether or not the break is set is a memory write message, that is, 'M <address>, <byte #>: <memory'. Value> 'message in the form of' M <address>, 1: cc ', it is determined that the brake is being set, and the release of the brake restores the same number of bytes to the <address> information used when setting the brake. See and judge the process.

FIG. 16 is a detailed flowchart illustrating a trace frame generation process described with reference to FIG. 15.

The trace frame generation unit 29 interprets the trace message through the tr message interpretation process when the message content is "tr" (S1501, S1502), and converts the virtual context ID value of the message into the new context ID when the message is "hg". The value is set (S1503, S1504).

The trace frame generation unit 29 changes the virtual register value to a new register value when the content of the message is “g” or “G” and resets it (S1505 to S1508). And the number of brakes (S1509, S1510).

Thereafter, the trace frame generation unit 29 changes the virtual memory value to a new memory value and resets it when the content of the message is "m" or "M" (S1511 to S1514), and the message content is "T". In this case, the trap message is interpreted and the CP, FP, and SP register values are changed (S1515 and S1516).

At this time, the virtual memory is made into a file, and the memory is refilled with the number of bytes from the address corresponding to the memory address. For example, for a target having 64 megabytes of memory, a file of 64 megabytes (MByte) is created, and the address is configured with the address of file 0 first.

Next, the trace frame generation unit 29 stops message interpretation when the message content is "W" (S1517 and S1518).

FIG. 17 is a detailed flowchart illustrating a tr message interpretation process of FIG. 16.

If the tr message is 'S' (1601), it leaves this module to read the next message, and if the tr message is one of 'mMgGT' (1602), it moves to the Restart point of FIG. 11A (1606). In the message format of tr (...) ', only the message part except' tr () 'is used to change the virtual register value and the memory value through the message interpretation module of FIG. 11B, and the tr message is' +'. Case 1603 and '*' (1604) indicate that the user trace area starts (1607) and ends (1608), respectively, and performs trace area start processing and end processing. When the tr message is 'U' (1605), the user trace dump data is stored in the target trace dump data file (1609).

As described above, the present invention receives a trace redo command for re-executing a trace from a user, and generates a trace redo frame composed of virtual registers and memory using logging information collected according to the trace execution according to the trace redo command. Detect and fix bugs in the application by analyzing the status of the application through existing debugging or redo dump commands, and analyzing trace dump data in the trace redo frame according to the trace dump command input from the user during the trace redo process. The program has been fixed by obtaining a certified application by fixing bugs, and saving the logging information to a file without stopping while the application is running and executing it again after the execution is completed. There is an effect that you can obtain an authentication program by debugging without losing the state of RAM.

Also, if the application measures the execution time from the start to the end of a specific function, the execution time is measured by looking at the time interval between two trace points using the trace dump command with the "-t" option during playback. By using the trace dump command with the "-u" option, you can examine the conversion status of a specific variable by processing time, which makes it possible to debug the user's desired part of the application.

Claims (11)

In the method of re-executing a trace using the logging data generated by the target for trace debugging the application in accordance with the trace point and the debugging command from the host, Receiving a trace redo command for redoing the trace and resetting the virtual memory and register values by reading and analyzing trace message information from the logging data; Generating the trace redo frame using the reset virtual memory and the register value according to the trace redo command; Analyzing trace dump data in the trace redo frame according to a trace dump command input during the trace redo process; And retrieving and fixing bugs of the application program using the trace dump data to obtain an authenticated application program. The method of claim 1, Executing the trace redo command, And determining whether the instruction for configuring the trace redo frame is a start, next, and stop instruction. The method according to claim 1 or 2, In the case where the determination result indicates that the trace redo frame command is started, Initializing information of the host and the target, wherein the target forms virtual memory and register information according to the logging information, and the host generates host trace frame information using the virtual memory and register information generated by the target; Wow, After generating the host trace frame information, the method further comprises reading the trace dump data from the target and writing the trace trace data to the user trace pump file of the host. . The method of claim 3, The host trace frame information, And a program counter information, a specific stack position of the application program and symbolic information of the stack. The method according to claim 1 or 2, If the trace redo frame command is next as a result of the determination, The target configures the trace frame corresponding to the next frame in the frame currently being re-executed, and the host configures the host trace frame using the trace frame configured in the target. How to redo a trace. The method according to claim 1 or 2, If the trace redo frame command is stopped as a result of the determination, Initializing the target and host and stopping execution of the trace. The method of claim 1, After resetting the virtual memory and register values, stopping analyzing the trace message information according to the number of breaks included in the logging data. The method of claim 1, The trace dump command, An authentication application having option information, wherein the trace history information of the target is read, the user trace dump data is read from the trace dump data, or the target trace dump data is read according to the option information. How to redo a trace to get a program. In a system that re-executes a trace using the logging data generated after trace debugging an application in which a trace point is set according to a trace debugging command, A host that receives and interprets a trace redo command for redoing the trace and sends the same through a remote function call function; According to the trace redo command received through the remote function call of the host, the virtual register and the memory information are set using the logging data, and the execution of the application is virtually reproduced, and the application is reproduced through the virtual reproduction of the application. A trace redo system to obtain an authenticated application comprising a target for detecting and fixing bugs in the program. The method of claim 9, The host, A trace command input unit for receiving the trace redo command; And a trace reproducing unit configured to interpret a trace reproducing command received from the trace command inputting unit and deliver a trace redo command to the target through the remote function call. The method of claim 9, The target, A trace data storage unit for storing logging data consisting of the virtual register and memory information when the application program is executed; And a trace frame generation unit configured to configure a trace frame having the virtual register and memory information using logging data stored in the trace data storage unit, and to virtually reproduce the application program using the trace frame. Trace redo system to obtain certified applications.