CN105824750A - Soft breakpoint simulation method during NorFlash program space debugging - Google Patents

Abstract

A kind of soft breakpoint simulation method of NorFlash program space debugging, comprises the steps: (1) processor coding stage, for the coding of soft breakpoint instruction, will be the coding format of all 0; (2) in NorFlash program space debugging stage , when the debugger needs to insert a breakpoint instruction into the program space, the debugger calls the breakpoint instruction insertion unit, which utilizes the feature that the NorFlash space can write the specified position from 1 to 0 according to a specific length, and inserts the processor's software Breakpoint instruction, that is, write all 0; (3) When the debugger receives the debugging request of the running program, judge whether the instruction at the current PC matches the breakpoint address in the soft breakpoint instruction list; (4) When processing After encountering a soft breakpoint instruction during the running of the debugger, the debugger should judge whether the address of this soft breakpoint instruction matches all the soft breakpoint addresses in the soft breakpoint module. The invention has high debugging efficiency and good applicability.

Description

A Soft Breakpoint Simulation Method for Debugging in NorFlash Program Space

technical field

The invention belongs to the field of debugging of a processor NorFlash program space, and in particular relates to a method for realizing a soft breakpoint in the debugging of a RISC embedded processor NorFlash program space. .

Background technique

In the development of embedded systems based on RISC processors, the development of read-only space (NorFlash, E ² PROM, etc.) In the reading space, the embedded device can be powered on and run directly on the Flash, and then it can work. Among read-only devices, NorFlash is favored by embedded devices for its linear address addressing and directly executable instructions.

For the RAM space, since the content of the space can be modified at will, developers only need to set soft breakpoints to control the running of the program. After the soft breakpoint is set, the first thing the debugger needs to do before running the program each time is to replace the instruction at the address where the soft breakpoint is set with the breakpoint instruction of the processor, and then run the program. After the breakpoint instruction, the information will be returned to the debugger, thus realizing the control of the program. Since the realization of soft breakpoints has no redundant hardware requirements for processor debugging, it is theoretically possible to set an infinite number of them.

Because NorFlash cannot support arbitrary write operations like RAM, so the existing NorFlash program space debugging basically requires hard breakpoints to complete the control of program running. If developers want to stop the program running in the NorFlash space somewhere, they need to Set a hard breakpoint here, the processor will receive the information that the debugger sets the hard breakpoint, and use its internal hardware resources to complete the setting of the hard breakpoint. If the program triggers the hard breakpoint during subsequent running, the processor will Information is returned to the debugger, allowing control of the program. The biggest problem with this method is that the implementation of hard breakpoints requires hardware overhead, and is proportional to the number of hardware breakpoints. For some extremely low-power embedded devices, the number of hard breakpoints may With only one (or even none), developers will not be able to set multiple breakpoints for program debugging while the control program is running; or after setting a hard breakpoint, they will not be able to detect the change of a variable in the program through the debugger observation point , because the implementation of the debugger's watchpoint consumes a hard breakpoint resource in the processor.

Due to the problem that the soft breakpoint instruction cannot be written or replaced in the read-only space, and the number of hardware breakpoints is limited, the efficiency of program development and debugging in the NorFlash program space is affected. In some extreme cases, certain debugging requirements cannot accomplish.

Contents of the invention

In order to overcome the shortcomings of low debugging efficiency and poor applicability in NorFlash program space in existing embedded development, the present invention provides a soft breakpoint simulation method for debugging in NorFlash program space with high debugging efficiency and good applicability.

The technical solution adopted by the present invention to solve its technical problems is:

A kind of soft breakpoint simulation method of NorFlash program space debugging, described soft breakpoint simulation method comprises the steps:

(1) In the processor encoding stage, for the encoding of the soft breakpoint instruction, it must be an encoding format of all 0s;

(2) In the NorFlash program space debugging stage, when the debugger needs to insert a breakpoint instruction into the program space, the debugger calls the breakpoint instruction insertion unit, which uses the NorFlash space to write the specified position from 1 according to a specific length The feature of 0, insert the soft breakpoint instruction of the processor, that is, write all 0;

(3) When the debugger receives the debugging request of the running program, it first judges whether the instruction at the current PC matches the breakpoint address in the soft breakpoint instruction list; if it does not match, it means that the soft breakpoint is the program itself command, the debugger can follow the original process and stop the execution of the program; if it matches, the following process will be executed:

(3.1) The debugger will analyze the binary instruction stream of the replaced processor at the PC, and output a formatted result, which includes the instruction type, instruction operand, and all exception types that may be generated by the instruction;

(3.2) The internal instruction execution unit of the debugger will first judge whether the instruction is abnormal according to the analysis result, and the judgment basis depends on the type of processor exception;

(3.3) If the instruction does not generate an exception, the debugger will read the operand part and the instruction type in the instruction parsing, call a specific debugging command, control the processor to complete the execution of the replaced instruction, and finally choose to stop according to the debugging command program, running program;

(3.4) If the instruction will generate an exception, the debugger should call the specified debugging command according to the analyzed exception type, set the processor to the specified abnormal state, and then continue to choose to stop and run the program according to the debugging command;

(3.5) If the instruction is executed normally, the debugger will execute the PC=PC+{current instruction length} operation; if the instruction execution will generate an exception, the debugger will execute PC=exception vector table [abnormal number], and jump to the exception entry for execution.

(4) When the processor encounters a soft breakpoint instruction during operation, the debugger should judge whether the address of this soft breakpoint instruction matches all the soft breakpoint addresses in the soft breakpoint module:

(4.1) If it matches, the debugger simulates the execution of this instruction as described in (3);

(4.2) If there is no match, no special action is required.

The technical idea of the present invention is: use the characteristic that the NorFlash device can write the saved value from 1 to 0 with a specific length; require that the soft breakpoint instruction code of the processor must be all 0, and the code length can be arbitrary; The debugging function is used to simulate the abnormal state of the processor and realize the instruction function of the processor.

The beneficial effects of the present invention are mainly manifested in: 1) the method realizes the insertion of soft breakpoints in the NorFlash program space, and simulates the execution of processor instructions, and indirectly realizes the function of hardware breakpoints in the manner of software simulation instruction execution, and solves the problem of breakpoints. Set a limited number of questions, thereby improving the debugging efficiency of embedded NorFlash space program debugging;

2) The implementation of this method does not occupy any hardware overhead, and it has high practical value in the field of embedded, which has limited requirements on resources;

3) This method saves hardware overhead in debugging embedded NorFlash, and can meet some debugging requirements that could not be met before in debugging a processor with limited hardware resources for debugging.

Description of drawings

Figure 1 is a block diagram of the NorFlash soft breakpoint simulation system;

Figure 2 is a flow chart of debugger breakpoint management;

Fig. 3 is a structural block diagram of a processor instruction simulation module;

Fig. 4 is a flow chart of the processor exception simulation unit.

detailed description

The present invention will be further described below in conjunction with the accompanying drawings.

With reference to Fig. 1～Fig. 4, a kind of soft breakpoint simulation method of debugging in NorFlash program space, described soft breakpoint simulation method comprises the steps:

(1) In the processor encoding stage, for the encoding of the soft breakpoint instruction, it must be an encoding format of all 0s;

(2) In the NorFlash program space debugging stage, when the debugger needs to insert a breakpoint instruction into the program space, the debugger calls the breakpoint instruction insertion unit, which uses the NorFlash space to write the specified position from 1 according to a specific length The feature of 0, insert the soft breakpoint instruction of the processor, that is, write all 0;

(3) When the debugger receives the debugging request of the running program, it first judges whether the instruction at the current PC matches the breakpoint address in the soft breakpoint instruction list; if it does not match, it means that the soft breakpoint is the program itself command, the debugger can follow the original process and stop the execution of the program; if it matches, the following process will be executed:

(3.1) The debugger will analyze the binary instruction stream of the replaced processor at the PC, and output a formatted result, which includes the instruction type, instruction operand, and all exception types that may be generated by the instruction;

(3.2) The internal instruction execution unit of the debugger will first judge whether the instruction is abnormal according to the analysis result, and the judgment basis depends on the type of processor exception;

(3.3) If the instruction does not generate an exception, the debugger will read the operand part and the instruction type in the instruction parsing, call a specific debugging command, control the processor to complete the execution of the replaced instruction, and finally choose to stop according to the debugging command program, running program;

(3.4) If the instruction will generate an exception, the debugger should call the specified debugging command according to the analyzed exception type, set the processor to the specified abnormal state, and then continue to choose to stop and run the program according to the debugging command;

(3.5) If the instruction is executed normally, the debugger will execute the PC=PC+{current instruction length} operation; if the instruction execution will generate an exception, the debugger will execute PC=exception vector table [abnormal number], and jump to the exception entry for execution.

(4) When the processor encounters a soft breakpoint instruction during operation, the debugger should judge whether the address of this soft breakpoint instruction matches all the soft breakpoint addresses in the soft breakpoint module:

(4.1) If it matches, the debugger simulates the execution of this instruction as described in (3);

(4.2) If there is no match, no special action is required.

In this embodiment, a command to start NorFlash program space debugging is added for the debugger. Because in the present invention, the soft breakpoint management method of NorFlash is completely different from the soft breakpoint implementation in general RAM, so it is necessary to add commands for debugging the NorFlash program space to the debugger.

Update the breakpoint management module of the debugger and add the NorFlash breakpoint writing unit; usually, NorFlash has the characteristic of writing a specific length from 1 to 0, and the debugger should use this characteristic to write processor breakpoint instructions. When NorFlash requires When the specified length is greater than the breakpoint instruction of the processor, for example, NorFlash requires to write in full word, but the breakpoint instruction is half word, at this time, the debugger can write the data containing the breakpoint 0xFFFF0000 in full word, because 1 It cannot be written normally, and the operation of writing breakpoints to the unit actually achieves the effect of writing half-word breakpoint instructions to NorFlash without affecting other program spaces.

Update the breakpoint management module of the debugger. When the set soft breakpoint is actually inserted into the NorFlash space, the debugger should record the breakpoint. Because the soft breakpoint instruction inserted in the NorFlash space cannot be modified, the debugger will Record the inserted breakpoint information in , regardless of whether the breakpoint is deleted; if the breakpoint is a soft breakpoint that has been deleted, then the debugger needs to simulate the execution of the instruction here, and then continue to run the program; when the breakpoint is not Delete, the debugger runs or stops the program according to the debugging command after the simulation completes the execution of the instruction here;

Update the debugger breakpoint management module. Whenever a command to run the program is received, the breakpoint management module intervenes in the debugger processing flow to detect the current instruction and check whether the current instruction is a soft breakpoint instruction for debugging. , if it is, the "processor instruction simulation module" will be started; (as shown in Figure 2); whenever the program stops and the debugger handles the memory viewing requirements, the breakpoint management module needs to intervene in the processing flow, when the memory range includes the When using a breakpoint instruction, it is necessary to replace the read target address with the code of the instruction recorded inside the debugger.

The processor instruction simulation module mainly includes three units (as shown in Figure 3):

The processor instruction parsing unit is responsible for parsing the binary instructions at the breakpoints saved in the debugger breakpoint management module into corresponding processor instructions. The output results include information such as the operand and register number of the instruction, and also include possible exception types.

Processor exception simulation unit; according to the output results in the instruction analysis unit, first find the list of possible exception types, and check whether each exception occurs. Take the detection of privilege violation exception as an example. The debugger can execute the command to view the processor status register , by checking the state of the processor, judge whether the current instruction exceeds the authority, and then enter the subsequent logical processing (as shown in Figure 4), when it is judged that an exception occurs, the exception processing unit will block the instruction from entering the instruction execution unit, and then according to the exception type, The debugger adjusts the processor state to the exception entry. Taking the privilege violation exception as an example, the debugger needs to perform the following logical steps:

1. Set the processor exception number as the privilege violation exception number;

2. Set the processor status register and PC to their corresponding shadow registers;

3. Clear the control bit and interrupt enable bit of the processor instruction trace;

4. Read the exception handling entry of the processor, and calculate the entry address of the privilege violation exception according to the exception vector number, then assign it to the PC, and finally run or stop the program according to the debugging command; when the exception handling unit judges that this instruction has no exception , the result output from the instruction parsing unit will be directly sent to the instruction execution unit;

The processor executes the simulation unit; reads the operands according to the output results of the processing analysis unit, and performs corresponding operations on the processor. Taking the privileged instruction [MFCRR0, PSR] as an example, this instruction is to set the status register of the processor To assign values to processor general-purpose registers, the debugger needs to perform the following logical steps:

1. Read the processor status register;

2. Update the value of the general-purpose register of the processor to the value of the read status register;

3. Adjust PC=PC+{breakpoint instruction length};

4. According to the debugging command, run or stop the program.

Claims (1)

1. the soft breakpoint analogy method in the debugging of the NorFlash program space, it is characterised in that: described soft breakpoint analogy method comprises the steps:

(1) processor coding stage, for the coding of soft break-poing instruction, the coded format of full 0 to be；

(2) stage is debugged in the NorFlash program space, when the demand of break-poing instruction is inserted in debugger oriented program space, debugger calls break-poing instruction and inserts unit, this unit utilizes NorFlash space can will specify the position feature from 1 write 0 according to length-specific, the soft break-poing instruction of insertion process device, i.e. writes full 0；

(3) when debugger receives the debugging request of operation program, first determine whether whether the instruction at current PC mates with the breakpoint address in soft break-poing instruction list；If it does not match, represent that this soft breakpoint is the instruction of program itself, debugger can be according to original flow process, the execution shut down procedure；If it does, then perform following flow process:

(3.1) examination device can resolve the binary command stream of the processor being replaced at PC, and output formatting result, this result comprises instruction type, instruction operands and instructs issuable whole Exception Type；

(3.2) first whether debugger built-in command performance element can judge instructing to produce according to analysis result extremely, it is judged that depending on according to processor Exception Type；

(3.3) if instruction will not produce exception, debugger can read the operand part during instruction resolves and instruction type, call specific debug command, control processor and complete this execution being replaced instruction, select to shut down procedure finally according to debug command, operation program；

(3.4) if instruction can produce exception, debugger should call the debug command specified according to the Exception Type resolved, be set to by processor in the abnormality specified, and then proceedes to select stopping, operation program according to debug command；

(3.5) performing if instruction is normal, debugger can perform PC=PC+{ present instruction length } operation；If instruction execution can produce exception, debugger can perform PC=exception vector table [anomalous sign], jumps to abnormal porch and performs.

(4), after running into soft break-poing instruction in processor runs, debugger should judge that this soft break-poing instruction address soft breakpoint address whole with soft breakpoint module mates:

(4.1) if it does, then performed this instruction by debugger simulation as described in (3)；

(4.2) if it does not match, need not do any special operational.