JP2683274B2 - Function trace output method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Outline] A trace method in an information processing apparatus, particularly a calling relationship of a subroutine (a function in C language) that constitutes a program, that is, a function or another function is called and a function that is the other way around is called. Regarding the output method of the function trace data that shows how to return from the function to the calling function, trace the execution of the program to reduce the amount of trace data output without causing a big trouble in the trace processing. Each time a constituent function calls or restores another function, the function that is called, the name of the function to restore to and the depth of the call are output in the trace process. When the value exceeds a certain value, the trace output is suppressed, and then a recovery is performed and the above It has a configuration that controls to restart the trace output from the point when the value returns to the value of.

[Industrial applications]

The present invention relates to a trace method in an information processing apparatus, and particularly, a calling relationship of a subroutine (a function in C language) that constitutes a program, that is, one function calls another function, and conversely a function returns to a calling function. The present invention relates to an output method of function trace data showing how to do.

Further, according to the present invention, the number of instruction execution steps of a program is divided by calling and returning a function, and the number of execution steps in each divided portion is information indicating the function being executed and the depth of the call at that time. It can also be applied to the trace output with.

[Conventional technology]

Figure 10 shows an outline of the trace processing mechanism in a conventional information processing device.

In Fig. 10, 1 is CPU, 2 is MS, 3 is OS, 4 is trace program, 5 is traced program, 6 is disk device, 7
Is a load module of the traced program 5, and 8 is a file area for trace output.

In operation, the trace program 4 loads the specified load module 7 to enable it to operate as the traced program 5.

With the help of OS2, the trace program 4 sets a breakpoint instruction at the function entrance of the traced program 5 and the return destination from the function, and detects the function call or return by using the stop at the execution time. Then, the trace data is collected and output to the file area.

Breakpoint instructions are set at all function entrances and their return destinations regardless of the depth of the function call, and trace data is collected.

[Problems to be solved by the invention]

One problem that occurs when executing a program while collecting trace information is the file area for outputting the trace information. This is a problem that as the execution time of the traced process increases, the trace output amount increases almost in proportion to it, and thus the prepared file area becomes insufficient. In general, it is often impossible to predict the trace output amount at the start of the trace processing, so there was a case where the file area became insufficient during the processing and the trace had to be aborted.

An object of the present invention is to reduce the amount of trace data output without causing a big trouble in the trace processing of outputting the trace information indicating the function name and the calling depth for the functions that are sequentially executed. There is.

[Means for solving the problem]

In the present invention, in general, when multiple function calls are made, the function to be called is often a library function prepared in the system, which is of little interest to the trace collector, The amount of trace data is reduced by monitoring the depth (level) of function calls during execution of the traced program and suppressing the output of trace data for function calls that exceed a predetermined depth. Is.

FIG. 1 is a principle diagram of the present invention. 11 is a CPU, 12 is a main memory M
S, 13 is the OS, 14 is the trace program, 15 is the traced program, 16 is the trace stack that saves the return instruction from the called function, 17 is the stack pointer, 18 is the disk device, and 19 is the trace data storage This is the file area to be used.

The traced program 15 includes a main routine main and subroutines (functions) sub1, sub2, and sub3.
in calls sub1, and sub1 calls sub2 and sub3.

The trace stack 16 stores a return destination instruction to the caller and its address each time a function call is made, and is removed from the stack when the return is made. The stack pointer 17 points to the stack position of the subroutine currently being processed. Stack pointer
The value of 17 represents the stack depth, that is, the function call depth.

[Action]

In FIG. 1, the trace program 14 collects the trace data each time a function call is made in the traced program 15, but the stack pointer 17
Is monitored and trace data is output to the file area 19 only when the depth is below a certain value.

For example, while the stack pointer 17 indicates a value of 3 or more in depth, even if the function trace data is collected, this is also not stored in the file area 19 of the disk device 18.

〔Example〕

FIG. 2 shows the structure of the function entry table provided in the trace program. This is an instruction that sets the function name, the entry address in main memory, the entry instruction (old instruction), and the breakpoint of the new instruction that replaces the old instruction for all functions that make up the traced program ( Since the instruction length of the breakpoint instruction is shorter than the settable unit determined by the OS, the right part of the old instruction remains when it is overlaid on the old instruction) is stored.

In this example, the traced program is main, sub1,
It consists of four sub2 and sub3.

FIG. 3 shows a trace stack provided in the trace program. Immediately after the execution of the main routine main begins, only the topmost line is used and the stack pointer points to 1. Immediately after main calls sub1, the stack pointer becomes 2, and information about sub1 is written on the second line. When a function calls another function, the stack pointer is incremented by 1, and information about the newly called function is written in that line.

When returning from the function to the caller, the stack pointer is decremented by one. Only valid values between 1 and the stack pointer value (inclusive).

FIG. 4 shows processing of each function limited to other function calling processing.

FIG. 5 shows changes in the contents of the trace stack during execution of main.

FIG. 6 (a) shows an example of trace data output, where the maximum output depth of trace output is not designated as in the conventional case. In this case, trace data of the progress of all function calls is output.

FIG. 6 (b) shows another example of trace output, in which the maximum output depth of trace output is specified as 2. Here, the trace output is limited to two stages, main and sub1.

FIG. 7 shows the initial processing executed by the trace program. The main purpose is to create a function entry table.

Explaining the flow in FIG. 7, the trace program first requests the OS to load the traced program and loads the load module. At this time, the load module information is also loaded.

Next, the trace program obtains the start address of the traced program loaded from the OS, reads the load module information, and obtains the entry address of all the functions of the traced program (by the real address).

Next, the old instruction at each function entry of the traced program is saved in the function entry table of FIG. 2 and a breakpoint instruction is set instead. At this time, the break point instruction is stored in the function entry table.

 Then the trace stack is initialized.

 The flow of FIG. 8 will be described.

When the traced program stops its execution, the trace program requests the OS to check the cause of the stop, and if it was stopped due to the execution of the breakpoint instruction, it checks the execution instruction immediately before the breakpoint instruction and calls that function call. If it is a Jsr instruction of (yes), the trace processing at the time of function call is performed, and in other cases (no), the trace processing at the time of returning from the function is performed.

In the trace processing at the time of function call, first, the function entry that matches the address of the breakpoint instruction that caused the stop is searched from the function entry table, and the Js of the calling source is searched.
The original instruction (becomes the old instruction) next to the r instruction and its address are saved in the trace stack of FIG. Here, the stack pointer is incremented by +1.

Next, set a breakpoint instruction at the address of the saved old instruction.

The stack pointer value is then compared to the specified maximum trace output depth value, and trace data is output if allowed.

On the other hand, in the trace processing when returning from a function, the address of the instruction (breakpoint instruction address) to be restored is first requested from the OS.

Next, if the address that matches that address in the trace stack is found (if it is one position before the stack position of the value of the stack pointer), the breakpoint instruction of the contents of that address is returned to the old instruction, and the stack pointer is set. −
Do one.

Then, it is checked whether the trace output is permitted for the depth of the stack pointer, and if it is permitted, the trace data is output.

FIG. 9 shows the setting status of break points in the traced program during the trace.

This is the state when main calls sub1, sub1 calls sub2, and sub2 is executing. The shaded area Indicates where the breakpoint is set.

〔The invention's effect〕

According to the present invention, by arbitrarily specifying the function call level for the trace output according to the traced program, the trace output amount can be suppressed to an appropriate scale, and the trace processing due to the lack of the file area can be suppressed. Stopping on the way can be avoided.

[Brief description of the drawings]

FIG. 1 is a principle diagram of the present invention, FIG. 2 is a configuration diagram of a function entry table used in the embodiment of the present invention, FIG. 3 is a configuration diagram of a trace stack used in the embodiment of the present invention, and FIG. 4 is a function call. 5 is an explanatory diagram of processing, FIG. 5 is an explanatory diagram of changes in the contents of the trace stack, FIG. 6 is an explanatory diagram of an example of trace data output,
FIG. 7 is a flow chart of an example of the initial processing of the trace program, FIG. 8 is a flow chart of the example of the trace processing, FIG. 9 is an explanatory view of the setting state of the breakpoint instruction, and FIG. 10 is an outline of the trace processing mechanism. It is a figure. In Figure 1, 11: CPU 12: Main memory MS 13: OS 14: Trace program 15: Traced program 16: Trace stack 17: Stack pointer 19: File area

Claims (1)

(57) [Claims] 1. A trace that traces the execution of a program and outputs the name of each called function, the function to which the function is restored, and the depth of the call each time another function is called or restored from a function that constitutes the program. In the processing, monitor the call depth, suppress the trace output when the call depth exceeds a certain value, and restart the trace output from the point when the call is restored and returns to the above certain value. A function trace output method that is controlled as follows.