JP5397648B2 - Source code tracer - Google Patents

Description

  The present invention relates to a source code tracer for facilitating debugging work of a program used in a program-type electronic information processing apparatus.

  In general, when a program is created for a program-type electronic information processing apparatus, a lot of time is spent on debugging the program. In order to make the program creation work more efficient, the debugging work time is required to be shortened, and a debugger or the like that facilitates the debugging work is often used.

  In general, a debugger provides a program with multiple breakpoints, temporarily suspends execution at each breakpoint, dumps the stored information at each point, and stores the stored information at each point. The operation of the program is verified by tracing.

  Further, as a tracer that performs debugging by observing the operation of the electromagnetic information processing apparatus without interrupting the operation, there is the following disclosure, for example.

  Patent Document 1 (Japanese Utility Model Laid-Open No. 5-17738) discloses a simple tracer. This is because the CPU signal is extracted by the CPU signal extraction circuit, the data set in advance in the comparison reference input setter and the extracted data (address / data) are input to the comparison circuit and compared, and the conditions match. When this happens, a signal is sent to the latch trigger determination circuit, and when the conditions match in the latch trigger determination circuit, the signal is sent to the latch circuit. The display circuit that receives the signal from the latch circuit receives the data at that time (CPU internal state) By using a configuration for displaying the CPU, it is possible to display the internal state of the CPU in real time or leave a trace with a simple circuit.

  Japanese Patent Laid-Open No. 6-348540 discloses a trace circuit and a trace method that improve the debugging efficiency by using a tracer when debugging a program written in a high-level language such as C language. Is disclosed. This has a circuit for latching a base pointer of a local variable and a circuit for latching a program execution address. At the time of data access, the contents of the base pointer latch and the contents of the program execution address latch are accessed. And write to the trace memory, calculate the variable offset of the local variable from the address recorded in the trace memory and the value of the base pointer, and use this variable offset and the program execution address in the trace memory to debug the debug information table of the program to be debugged And the data access content recorded in the trace memory is associated with the local variable.

  Further, Patent Document 3 (Japanese Patent Laid-Open No. 8-335177) discloses a processor operation observation method and apparatus for performing a program trace while operating an instruction cache. The CPU used here outputs the instruction address to the external bus of the CPU via the memory address register regardless of whether the instruction specified by the instruction address exists in the instruction cache. This external bus consists of an address bus, a data bus, and a control bus. When debugging a program, a processor operation observation device is connected to this external bus, and even if the instruction cache hits, the instruction accessed by the CPU The external memory address and bus status are stored in the trace memory of the processor operation observation apparatus. By reading the trace memory and analyzing the contents of the address and bus status, the execution process of the instruction executed by the CPU is traced.

  Japanese Patent Laid-Open No. 10-21118 discloses a debugging system. In this case, a designated address is set by an address setting unit of a computer (PC), and a memory read request is sent from the read request unit to the debug target device via an interface cable. In the device to be debugged, the memory read unit dumps the contents of the designated address of the memory in response to the memory read request, and returns it to the PC 1 via the interface cable. A designated address is set by the address setting unit of the PC, write data is set by the data setting unit, and a memory write request is sent from the write request unit to the debug target device via the interface cable. In the debug target device, the memory write unit 23 writes write data to a specified address in the memory in response to a memory write request.

  In Patent Document 5 (Japanese Patent Laid-Open No. 2001-175510), the same data that is repeatedly generated is not recorded, and only the data necessary for debugging and failure analysis is reliably collected, thereby efficiently tracing. A trace data compression method and a trace data compression method using a buffer are disclosed. This is because, in a tracer that periodically records a plurality of state values inside an LSI, the trace data is divided into a first field where the state value changes frequently and a second field where the state value changes less frequently. If the data of the second field of the latest registered trace data matches the data of the second field of the received trace data, the data of the second field of the received trace data is Do not register. When registering the received trace data, each of the data in the first field and the second field is registered with an identifier.

  Patent Document 6 (Japanese Patent Laid-Open No. 2001-331344) discloses a failure information tracer device for an embedded system that can notify the background of the failure occurrence based on the history information of the system program and can smoothly analyze the cause of the failure. . This failure information tracer device is composed of an execution format program, an execution history collection unit for organizing history information, a trace memory for storing history information, and a debug monitor for dumping the stored contents to the device under test. The device under test consists of debugger software that introduces history information, a trace memory dump result file in which history information is filed, a program source file group, and a trace information analysis program that outputs the relevant location for failure analysis. Is.

  Patent Document 7 (US Pat. No. 6,161,216) describes a method and apparatus for debugging source code using a source code debugger. In this case, the script generator receives instructions of the source code. The script generator reads source code instructions and automatically generates a debug script that satisfies the tracepoint specifications based on the type of instruction that defines the execution block or control boundary. Pass this debug script to the source code debugger.

  The inventions described in Patent Documents 1 to 6 differ from the present invention in that the program is not modified so as to positively output debugging information. The invention described in Patent Document 7 differs from the present invention in that a script generator that generates a debug script is used.

Japanese Utility Model Publication No. 5-17738 JP-A-6-348540 JP-A-8-335177 Japanese Patent Laid-Open No. 10-21118 JP 2001-175510 A JP 2001-331344 A US Pat. No. 6,161,216

  The program can be debugged more efficiently, and it is also easy to debug runtime errors that occur less frequently.

  A source code tracer according to the present invention includes a target device that is a program-type electronic information processing apparatus, and a computer that compiles a source code that is a program of the target device and inserts a debug line during the compilation (hereinafter referred to as a first computer). A data collector that selectively collects and stores data from the address bus, data bus, or control bus of the target device, and transmits the collected data from the data collector to an external computer (hereinafter referred to as a second computer). The debug line is used for debugging and includes debug information including position information on the source code of the debug line on the data bus for a predetermined address on the address bus of the target device. Output as debug data The target device includes a semiconductor memory that requires a predetermined write procedure, and outputs a write code that does not include the write procedure to an address assigned to the semiconductor memory. It is characterized by using lines.

  Further, the debug line has contents for outputting debug information further including time information passing through the debug line as the debug data.

  The data collector selectively collects and stores data from the data bus or the control bus when a signal on the address bus of the target device matches at least one predetermined address. .

  The data collector compresses and stores the collected data.

  The second computer compares the scheduled trace information with the debug data, and outputs information related to the debugging of the source code.

  When the target device includes a semiconductor memory that requires a predetermined write procedure, for example, an EEPROM or a flash memory, a write code that does not include the write procedure is sent to an address assigned to the semiconductor memory. By using a debug line that performs pseudo writing, the number of addresses to which debug data is output can be increased.

  Since the debugging operation can proceed without interrupting the program processing, the debugging operation can be performed in a state closer to the actual operation as compared with the conventional example in which the processing is interrupted.

  In addition, since the actual program processing can be performed without any trouble even if the debug line is left, the verified program can be applied to the actual processing.

  In addition, as described above, debugging can be performed without reducing the program processing speed, so that more debugging lines can be inserted into the source code than before, making debugging easier. Can be.

It is a figure which shows the example of the electronic information processing apparatus of the program system which is a target device to which the source code tracer of this invention is applied. It is a figure which shows the structural example in the case of applying the source code tracer of this invention to a target device. It is a figure which shows the structural example of a data collector. It is a figure which shows the flow of a process in the test assistance system using the source code tracer of this invention. It is a figure which shows the flow of the analysis using the source code tracer of this invention. It is a figure which shows the flowchart in the case of debugging using the conventional debugger. It is a figure which shows the flowchart in the case of debugging using the source code tracer of this invention.

  Embodiments of the present invention will be described below in detail with reference to the drawings. In the following description, devices having the same function or similar functions are denoted by the same reference numerals unless there is a special reason.

  FIG. 1 is a target device 30 to which a source code tracer of the present invention is applied, and is a program-type electronic information processing apparatus. In the target device 30, an arithmetic unit (CPU) 31, a memory 32, and an input / output circuit 33 are connected by a control bus 34, an address bus 35, and a data bus 36. The input / output circuit 33 is provided with an expansion bus 37 directed to various interfaces.

  FIG. 2 shows a configuration example when the source code tracer 100 of the present invention is applied to the target device 30. The source code tracer 100 of the present invention includes a data collector 10 and a computer (PC) 7 connected thereto. The data collector 10 is connected to the control bus 34, the address bus 35 and the data bus 36 of the target device 30 through the repeater 20. Further, one of the expansion buses 37 and the PC 7 are connected. Here, the computer connected to the expansion bus 37 may be another computer.

FIG. 3 is a diagram illustrating a configuration example of the data collector 10. Data from the repeater 20 is sent to the selector 1, and the address bus is monitored, and the data on the data bus sent to a predetermined address is taken in. Here, a plurality of addresses may be designated in advance, and each address may be properly used for each purpose.
In the data processor 2, the acquired data is analyzed, organized, compressed as necessary, and stored in the memory 4. For this compression, a compression method already well known for compressing two-dimensional digital data can be used. As the simplest method, there is a compression method that adds repetition frequency when the same data continues, but this method may be used.
In this part, the amount of data processing increases, so it is desirable to use a high-speed digital signal processor such as a multi-core, for example. The data stored in the memory 4 is sent to the PC 7 in FIG. 2 through the USB 6 using an input / output (I / O) device 3, for example, a USB (Universal Serial Bus) transceiver. The ROM (read-only memory) 5 may be an electrically rewritable memory, and is a device that stores a program for the input / output (I / O) device 3, but is built in the USB transceiver. If it is, there is no need to provide it outside.

Next, a debugging operation using the source code tracer 100 of the present invention will be described with reference to FIGS.
FIG. 4 is a diagram showing the flow of processing in the test support system using the source code tracer of the present invention. In FIG. 4A, the source code is analyzed, and the log code that does not affect the execution of the program is automatically inserted at the entry / exit of the function or branch processing. In FIG. 4B, the execution of the log code is detected and recorded. In FIG. 4C, the recorded data is analyzed, collated with the source code and the test pattern, and the program execution status and the verification result are graphically expressed. Also, in FIG. 4D, the log code incorporation location is changed and re-executed. By processing in this way, the evaluation result can be stored online and managed for each version. Also, by outputting the verification result in a form, it can be used as a document for product inspection certification.
FIG. 5 is a diagram showing the flow of analysis using the source code tracer of the present invention. In FIG. 5A, the program is executed on the real device. In FIG. 5B, the memory tracer detects that the log code previously incorporated in the program has been executed, collects the output information, and sends it to the PC. In FIG. 5C, in order to be able to quickly detect and analyze a potential problem, the execution state of the program is displayed so as to be captured visually. In FIG. 5D, if a problem is found in the program, it is corrected and executed again. In FIG. 5E, the process is completed when there is no problem. At this time, the used data becomes a document that guarantees the quality of the program.

(1) Source code embedding (FIG. 4 (A)) A code for writing data to an address for outputting to an external bus that is not normally used by the target device except for debugging work (hereinafter referred to as a trace code). ) Is embedded.
In embedding the trace code, the trace code is embedded so that it can be recognized in which part of the source code is embedded by a combination of an address and data. For example, in the case of the C language, the information that becomes points is the beginning and end of one function, immediately after a branch instruction, information on variables, and the like.
This embedding work is executed on the PC 7 using a dedicated application. Obviously, it may be performed on another independent computer.

  As a feature of this method, it is possible to execute a trace code by reducing the load on the CPU because it is writing to an address of an external bus that is not used. Further, in the output of the trace code, by enabling the position of the debug line to be determined by the combination of the address and the data, the place where the debug line can be embedded is significantly increased compared to the conventional case.

  Further, when the target device includes a semiconductor memory such as a flash memory or an EEPROM that requires a predetermined writing procedure at the time of writing, the semiconductor memory is not actually written but is written. By performing pseudo-writing that behaves like this, the address assigned to the semiconductor memory can also be used to output the trace code. In order to perform this pseudo-write, a write procedure that deviates from the predetermined write procedure is performed as follows.

For example, in the case of a JEDEC (Semiconductor Technology Association) standard command compatible flash memory, the write procedure is performed by issuing a command to a predetermined address. This command is binary data on the data bus. For example, in the case of a 16-bit data bus? As an arbitrary value from 0 to F in hexadecimal notation,
? ? 29? ? 30 ,? ? 80? ? 90? ? A0? ? B0? ? F0,
As address = (????????? A4, ?????? 54),
The writing procedure is completed by writing.

  Obviously, in order to prevent this writing from being performed for any address value in this memory, it is sufficient to prevent the generation of the above data. For example, the trace code may be output using a set obtained by removing the above value from 16-bit data. Data conversion is performed as necessary. A particularly simple example is, for example,? ? 00 is output as ASCII data, so that pseudo writing can be performed without actually writing.

  The embedding of the present invention can reduce the load on the CPU compared to the conventional method of outputting information to a communication bus such as UART (Universal Asynchronous Receiver Transmitter), and also compared with the method of outputting to GPIO (general-purpose port). In the method of storing information in the internal memory, it is necessary to connect an emulator or the like, and the usage scene is limited. However, in the present invention, debugging can be performed using an actual machine.

(2) Compile and check operation Compile source code with embedded trace code, transfer it to various targets, run the above compiled trace code on the target device, and check the sequence according to the actual operation. (FIG. 5A).

(3) Extraction of output code and transfer to PC (FIGS. 4B and 5B)
The data collector 10 takes in the data discharged from the target by the trace code and transfers it to the PC 7. In addition, operations such as start of capture and stop of capture are performed on the PC 7 using a dedicated application. If it is not necessary to capture all the data discharged from the target, an address to be captured from the PC 7 to the data collector 10 is set and selected. Since the data collector 10 needs to perform data processing at high speed, it is desirable to use a dedicated digital signal processor (DSP) configured using a multi-core general-purpose microprocessor or a gate array.
Further, when the data collector 10 captures the waveform output to the external bus of the CPU, the data at the address to which the information is output is added to the memory 4 by adding the time stamp of the target device or the source code tracer. store. When the data is accumulated in the fixed amount memory, the data is sequentially transferred to the analyzer (PC 7). Alternatively, transfer is performed according to a request from the PC 7.
Information to be collected includes, for example, (1) which part of the program was executed when and (2) which part of the program is set to the variable specified in the information. is there.

(4) Analysis of output data (FIG. 4C)
Next, the data transferred to the PC 7 by the data collector 10 (hereinafter referred to as log data) is analyzed on the PC 7 with a dedicated application. It is obvious that this analysis can be performed by another computer, but in this embodiment, the processing is performed with as few apparatuses as possible.
As for this analysis, as shown in FIG. 5C, it is desirable to visually capture the execution status of the program and display it so that a potential problem can be detected and analyzed quickly.
For example, the following matters can be clarified by the analysis here.
(1) By confirming the execution order of the program, it is possible to confirm the difference from the design block, and it is possible to find an abnormal part and prove that it is operating normally.
(2) Whether the real-time performance of the program, such as the time taken for processing between each debug line and the interval at which the processing is executed, is the result of abnormal operation or normal operation from the time stamp information at the time of program execution It is possible to determine whether or not.

  (FIG. 4D) The program creation is completed by repeatedly performing the food back to the source code from the above analysis result. In other words, the user analyzes the analysis result against his / her design philosophy, corrects the abnormal part and changes the source code, and executes the above (1) to (4) to ensure consistency with the design philosophy. To increase. Further, as shown in FIG. 5E, if there is no problem, the used data can be used as a document for guaranteeing the quality of the program as it is.

  In developing the program, debugging work is required. The flowchart is shown in FIG. 6 for the conventional case and in FIG. 7 for the case of using the source code tracer of the present invention.

  In FIG. 6, a program C1 to be debugged is decomposed for each function at C2, and divided into modules in each function classification at C3. In C20, a function test specification is created along the disassembly for each function, and in C21, a module test specification reflecting the division into each module is created. For example, module A is divided for each function at C4. For example, in the function A, the function is designed with C5. In designing this function, the data structure and control structure are also determined. Source code is created based on this design in C6. The source code is verified in C7, and the source code is debugged until the required specification is satisfied in C8. These results are compiled into a unit test result report in C22. If each module satisfies the required specifications, then a coupling test is performed in a state where the modules are coupled in C9, and the combined test result report in C23 is collected. If the combined test standard is passed in C10, a comprehensive test combining the functions is performed in C11, and the result is compiled in a C24 comprehensive test result report. In addition, a software change verification report is issued at C25. This is a report on the verification results after changing the program. If the overall test standard is passed in C22, program development is completed in C13.

  In FIG. 7, the program P1 to be debugged is decomposed for each function at P2, and is divided into modules in each function classification at P3. In P20, a function test specification is created along the disassembly for each function. For example, module A is divided for each function at P4. For example, in function A, a function is designed in P5. In designing this function, the data structure and control structure are also determined. At P6, source code is created based on this design. Next, in P7, the trace code which is one of the features of the present invention is embedded. Along with this embedding, a module test specification is created at P21. The source code in which the trace code is embedded is integrated at P8. In the operation verification, it is not always necessary to prepare all the modules and all the functional parts, and the verification work can be performed from the one that can be operated. When the above integrated source code is executed at P9, each trace code is output to a predetermined address. By collecting and classifying these trace codes with the source code tracer of the present invention, the unit test and combination described above are performed. A result equivalent to the case where the test or the comprehensive test is simultaneously performed can be obtained. Further, the unit test result report can be obtained at P22, the combined test result report at P23, and the comprehensive test result report at P24. When a program is changed, a software change verification report is issued for the verification result.

  As described above, by using the source code tracer of the present invention, the verification work can be performed in a lump, and the verification work can be performed in a state where it is actually used, so that the debugging work becomes efficient and easier. Verification can be performed.

  The connection between the repeater 20 and the external memory bus of the CPU is performed by soldering with a dedicated flexible printed circuit (FPC) or by providing a test socket for connection. Thus, it is possible to make electrical connection while suppressing a decrease in impedance. If it is not a high-speed external memory bus, a socket can be used to connect the CPU and the board, and a clogged socket for pulling out wiring can be used as the socket. It is also possible to optically extract a digital signal using an electro-optic crystal.

  If a design target value such as the time required from another debug line is added to the comment part of the debug line to be inserted into the source code in a predetermined format, this target value is compared with the actually collected data. Debugging functions can be made more efficient. By developing this function, the designer adds various design target values to the comment part that does not become executable code in the source code at the design stage, so that this target value is compared with actual data. be able to. By utilizing this function, an automatic test determination system can be realized.

  It is well known that it is easy to convert serial data to parallel data. As a result, it can be seen that the present invention can be easily applied not only to a parallel external bus as a test code output destination but also to a serial external bus.

1 Selector 2 Data Processor 3 Input / Output (I / O) Unit 4 Memory 5 ROM (Read Only Memory)
6 USB (Universal Serial Bus)
7 Computer (PC)
8 Expansion bus 10 Data collector 20 Repeater 30 Target device 31 Arithmetic unit (CPU)
32 Memory 33 Input / output circuit 34 Control bus 35 Address bus 36 Data bus 37 Expansion bus 100 Source code tracer

Claims (5)

A target device which is a program-type electronic information processing apparatus;
A computer (hereinafter referred to as a first computer) that compiles a source code that is a program of the target device and inserts a debug line at the time of compilation;
A data collector that selectively collects and stores data from an address bus, data bus, or control bus of the target device;
A communication path for transmitting collected data from the data collector to an external computer (hereinafter, second computer),
The debug line is used to debug and includes debug information including position information on the source code of the debug line as debug data on the data bus for a predetermined address on the address bus of the target device. Is,
The target device includes a semiconductor memory that requires a predetermined write procedure, and uses a debug line that outputs a write code that does not include the write procedure to an address assigned to the semiconductor memory. Source code tracer.   2. The source code tracer according to claim 1, wherein the debug line has contents for outputting debug information further including time information passing through the debug line as the debug data.   The data collector selectively collects and stores data from the data bus or the control bus when a signal on the address bus of the target device matches at least one predetermined address. 3. The source code tracer according to claim 1, wherein the source code tracer is characterized in that   3. The source code tracer according to claim 1, wherein the data collector stores the collected data in a compressed manner.   5. The second computer according to claim 1, wherein the second computer compares scheduled trace information with the debug data, and outputs information related to debugging of the source code. 6. Source code tracer.

Images