JPH0310339A - Debugging method with functional step function - Google Patents

Abstract

PURPOSE:To obtain a functional step function by outputting arguments of functions and function values (return values) while executing steps with a function as the unit. CONSTITUTION:A host machine 1 is provided with a debugger and a user object file, and an incircuit emulator 2 is connected to the host machine 1 by a bus 3. The debugger transfers information of all functions corresponding to object modules to the incircuit emulator 2, and break points are set to heads of functions in the incircuit emulator 2 based on this information. At the time of break, the break point is set to the return address of a function and the argument is returned to the debugger in case of the head of the function, and the break point is reset and the function value is returned to the debugger when the break point is the return address. Thus, the step operation is apparent ly performed with a function as the unit when an execution command GO is issued from the debugger.

Description

[Detailed Description of the Invention] <Industrial Application Field> The present invention relates to a method for debugging a program written in C language. Regarding how to make it work.

<Conventional technology> In-circuit emulators for microprocessors are
It is used when developing and debugging microprocessor application equipment. This in-circuit emulator has the function of depacking a program to the Targetera 1 by executing it while stopping the Targetera 1 to Mike 1 coprocessors for each instruction. In recent years, with the spread of high-level languages (such as the C language), some programs have appeared that have the ability to perform depacking at a high-level language level by stopping and running each source line in the high-level language. (For example, if the applicant did not apply for a patent application in 1983,
No. 1675).

<Problem to be solved by the invention> By the way, do programmers who develop C programs treat lines and functions as the basic units when depacking?
In the debugger using Kaki's in-circuit emulator mentioned above, there was a concept of line stepping as a depacking function for lines, but there was no concept of a step function for each function.

Furthermore, while the basic unit in system debugging is a line, the basic unit in system debugging is often a function, and checking the validity of the input/output condition values of a function is the first phase of bug factor analysis. Unit debugging functionality is highly desired.

Conventional in-circuit emulators have had the problem of not being able to fully depack each function.

The purpose of the present invention has been made in view of the above points, and when depacking a program written in C language using an in-circuit emulator, the function argument (argument) is The object of the present invention is to provide a debugging method that has a function step function that outputs a function value (also called a return value).

Means for Solving the Problems> FIG. 1 is a flowchart of the principle of the debugging method of the present invention. In the present invention, the in-circuit emulator
- It is a configuration controlled by an in-circuit emulator control tool (so-called debugger) on the machine, and all depacking functions are possible only when the upper debugger and in-circuit emulator are combined.

(1) First, the in-circuit emulator receives information on all functions (address, arguments 1-3 function values) corresponding to the object module from the debugger.

■In the Incircler I emulator, set this information in the break RAM.

-Based on the set information, the in-circuit emulator sets information on the processing to be performed within the in-circuit emulator after the break is established in the break management table in the information table.

■When the in-circuit emulator is executed by the execution command Go from the debugger and breaks, (1) If the breakpoint l- is the function head, set the breakpoint) to the return address and set the argument Transfer the current program counter to the debugger.

(2) If it is a breakpoint or a return address of a function, reset the current breakpoint and transfer the function value from the program counter to the debugger.

(3) If the break point l- is not the head or return address of the function, perform other break processing.

<Operation> The debugger transfers information on all functions corresponding to object 1-module to the in-circuit emulator,
Based on this information in the in-circuit emulator, a break point I is set to cell 1 at the head of the function.

In the in-circuit emulator, when a break occurs,
If it is the head of a function, set a breakpoint at the return address of the function and return the argument to the debugger, and if breakpoint 1 is the return address when breaking, reset the breakpoint and return the function value to the debugger. .

As a result, when the execution command Go is issued from the debugger, it is possible to realize what appears to be a sudump operation in units of two functions.

Note that, as a step unit of a function step, one step is the time when the head or return address of the function is reached.

<Example> FIG. 2 is a configuration diagram of a system for implementing the depacking method according to the present invention. 1 is a host machine, which has a debugger and a user object l-file. Reference numeral 2 denotes an in-circuit emulator, which is connected to the host 1 and the machine 1 by a bus 3.

In-circuit emulator 2 has break RAM that allows you to set breakpoints for each function.
In addition to the normal processing functions, it creates a breakpoint l-management table based on the function information transferred from boss 1 to machine 1, and handles break address settings, arguments, program counters, and function value post 1. - Has functions such as transfer to machine 1.

In such a configuration, as a preprocessing stage, the in-circuit emulator 2 receives information (address, argument, , function value) and set a break point (black circle) at the head of each function as shown in the conceptual diagram of the break RAM in FIG. At the same time, information on the processing to be performed within the in-circuit emulator after the break is established is set in the information table in the breakpoint 1 to management table as shown in FIG.

When the execution command Go is issued from the higher-level debugger and the program is executed in the in-circuit killer 1 emulator and breaks, the in-circuit error occurs depending on whether break point 1 is the function head, the return address, or none of the above. The emulator's processing is divided into the following parts.

(2) If it is a function head, refer to the breakpoint 1~ management table, set breakpoint 1~ at the return address of the break function, and transfer the argument and current program counter value to the debugger.

(2) If it is a return address to breakpoint 1, the in-circuit emulator executes the function, resets the current breakpoint, and transfers the function value and program counter to the debugger.

■If neither is the case, execute another break process.

The following two step operations are illustrated in an explanatory diagram as shown in FIG. That is, when function steps from Karen 1 to Row are issued in sequence, the steps are completed in the order of ■ to ■.

However, ■ and ■ indicate the head of the function, and ■ and ■ indicate the return address.

<Effects of the Invention> As described above in detail, the present invention has the following effects.

■It is possible to perform step operations using functions as units.

■It is possible to display the input conditions (argument values) and output conditions (function values) of functions, which are key points for debugging.

■Continuously issue this function with a count (own l-
With the attached function step), it is possible to race the function calling order and execution transition from 1 to 1.

■In the Inser-Kit emulator, breakpoints are set for each function, and execution between them is performed continuously, so real-time operation between functions can be guaranteed.

■Since function information is provided within the in-circuit emulator, complicated communication sequences with the host debugger can be omitted. Therefore, it is possible to improve the response.

[Brief explanation of drawings]

Fig. 1 shows the principle flow of the depacking method of the present invention. Fig. 2 is a block diagram of a system for implementing the method of the present invention. Fig. 3 is a conceptual block diagram showing the function points of the break RAM. The figure shows a breakpoint management table, and FIG. 5 is a diagram for explaining function step operation. 1... Host 1 to machine, 2... In-circuit emulator, 3... Bus. 7th figure function A between 7ff A

Claims (1)

[Claims] A host machine having a debugger and a user object file, and a break RAM capable of setting breakpoints for each function, and a breakpoint management table based on function information transferred from the host machine. It consists of an in-circuit emulator that has functions such as setting break addresses, transferring arguments, program counters, and function values to the host machine, and all debugging functions are only available when the upper debugger and in-circuit emulator are connected. In a system configured to allow this, the in-circuit emulator has the process of receiving from the debugger the information addresses, arguments, and function values of all functions corresponding to the object module, and breaking this information within the in-circuit emulator.
A step in which the in-circuit emulator sets information about the processing to be performed within the in-circuit emulator after a break is established in the break management table based on the set information in the in-circuit emulator, When the execution command is executed and a break occurs, (1) If the breakpoint is at the function head, set the breakpoint at the return address and transfer the arguments and current program counter to the debugger, (2) If the breakpoint is at the function head, (3) If the breakpoint is not the head or return address of the function, reset the current breakpoint and transfer the function value from the program counter to the debugger; (3) If the breakpoint is not the head or return address of the function, perform other break processing. A debugging method having a function step function, characterized by comprising steps as follows.