Source level debugger for debugging source programs

Data processing: software development – installation – and managem – Software program development tool – Testing or debugging

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C717S128000, C719S323000

Reexamination Certificate

active

06550056

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a source-level debugger for debugging source programs for use with computers adopting a pipeline processing method.
2. Description of the Prior Art
Referring now to
FIG. 24
, there is illustrated a timing chart showing the operation of a prior art source-level debugger. In system debugging using a source-level debugger, the execution of a source program can be halted (or suspended) by a stop command, a step command, a breakpoint, or the like. Such a halt on the source program's execution suspends the execution of an instruction currently being executed. After that, the contents of a memory, registers, and variables can be displayed. For example, when a breakpoint is set to an instruction “ld24 r5, 2000”, which is a load instruction to load the contents of a memory location at address 2000 into a register R
5
, as shown in
FIG. 24
, the source-level debugger stops the source program's execution at a clock cycle CC
5
. As a result, the write stage of the preceding sub instruction and the memory access and write stages of the ld24 instruction remain to be processed when the source program's execution is halted at the clock cycle CC
5
. The system (or program) execution is thus halted before reading and storing the contents of the memory location at address
200
in the register R
5
. Accordingly, in the case of microprocessors having a pipeline structure, data associated with an instruction that remains to be executed completely upon a halt on a source program's execution remains to be stored in the memory and/or registers, and variables in the pipeline.
That is because a halt on the execution of an instruction by the source-level debugger is done at the execution stage of the instruction in the pipeline processing. Therefore, when the source-level debugger halts a source-program's execution at a breakpoint placed at an instruction such as a store or load instruction, the data write stage (or write backstage) to write data into either a destination memory location or a destination register and so on is not executed after the execution of the execution stage of the instruction. Accordingly, in the above-mentioned example as shown in
FIG. 24
, a register window of the source-level debugger shows that the contents of the register R
5
are 0. However, if the write stage of the “ld24”, instruction is actually executed, it is shown that the contents of the register R
5
are FF.
In the case of in-circuit emulators or ICEs, when the source-level debugger reaches an instruction at which the source program's execution is to be halted, it halts the source program's execution by interrupting a microcomputer. When the instruction being executed needs to write data into a memory and/or a register, and a corresponding variable in a microprocessor in which an interruption occurs, the microcomputer can advance to the write back stage by automatically inserting a specific instruction such as a nop instruction into the source program. In the example as shown in
FIG. 24
, the source-level debugger advances to the clock cycle CC
7
and then retrieves the contents of the register R
5
. As a result, the source-level debugger can display the contents of the memory and/or registers, and variables, which have been updated after the completion of the instruction at which the source program's was halted. However, since ICEs advance the clock cycle by automatically inserting a specific instruction such as a nop instruction into the source program, as mentioned above, it cannot halt the execution of the source program while holding the contents (or internal state) of the pipeline. In the example as shown in
FIG. 24
, the source-level debugger does not execute the next xor instruction placed just behind the ld24 instruction when it halts the execution of the source program at the ld24 instruction, thus corrupting the contents of the pipeline.
Since the contents of the pipeline differ from its original contents when DMA transfer is carried out during the execution of the write back stage, in real systems, the prior art source-level debugger cannot debug the source program while making the source program run in the same way that it runs on real systems. On the other hand, instruction set simulators cannot simulate the pipeline processing because a source program is executed in units of an assembly-level instruction.
On the other hand, although cycle (or clock)-based simulators can halt a source program's execution while holding the contents of the pipeline, as previously mentioned, the contents of the memory and so on remain to be processed in the pipeline. Thus the source-level debugger cannot display the contents of the pipeline, i.e., the data that remains to be processed in the pipeline.
A problem with a prior art source-level debugger constructed as above is that when it halts or terminates a source program's execution, it cannot display the internal state of the pipeline, e.g., data that remains to be processed in the pipeline. Accordingly, users, such as program developers, cannot recognize the contents of the pipeline, which must be displayed if an instruction that has been halted is executed completely, and therefore cannot grasp operating conditions of real systems.
Another problem with a prior art source-level debugger is that it does not have a user interface to allow users to determine whether the contents of a cache memory in a microprocessor match the contents of part of a memory that have been taken in by the cache memory.
A further problem with a prior art source-level debugger is that although it can debug a source program while executing the source program step by step in units of one instruction by issuing a step execution command, it cannot set a breakpoint for specifying a clock cycle at which the execution of a source program is to be halted and execute the source program step by step in units of one clock cycle, and therefore it cannot debug a corresponding real system at a clock cycle level.
SUMMARY OF THE INVENTION
The present invention is made to overcome the above problems. It is therefore an object of the present invention to provide a source-level debugger capable of, when halting (or suspending) or terminating a source program's execution, showing the internal state of the pipeline.
It is another object of the present invention to provide a source-level debugger capable of allowing users to determine whether the contents of a cache memory in a microprocessor match the contents of part of a memory that have been taken in by the cache memory.
It is a further object of the present invention to provide a source-level debugger capable of debugging a source program at a clock cycle level by executing the source program step by step in units of one clock cycle.
In accordance with one aspect of the present invention, there is provided a source-level debugger for debugging a source program for computers using a pipeline control method. The debugger comprises: a) a not-yet-processed instruction analyzing unit for analyzing each of instructions including not-yet-processed stages in a pipeline when execution of a source program is halted or terminated, and for acquiring information on an internal state of the pipeline and b) a displaying unit for displaying the information on the internal state of the pipeline acquired by the not-yet-processed instruction analyzing unit in a predetermined display form.
In accordance with a preferred embodiment of the present invention, if data, which is associated with each of the instructions, remains to be processed in the pipeline when the execution of the source program is halted or terminated, the not-yet-processed instruction analyzing unit identifies at least one of a destination memory location and a destination register and a corresponding variable therein, into which the data that remains to be processed in the pipeline is to be written, and then furnishes the identification result as the information on t

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Source level debugger for debugging source programs does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Source level debugger for debugging source programs, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Source level debugger for debugging source programs will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3004590

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.