Method for quickly positioning problem after operation fault of bare computer program

Abstract

The invention relates to the field of bare computer program problem positioning, and particularly provides a method for quickly positioning a problem after a bare computer program operation fault, which comprises the following steps of: adding a compiling option-g-O0 in a bare computer program; the method comprises the following steps: adding an exception vector table of a bare computer program in a code for assembling the bare computer program, defining, reading and printing values of an exception link register ELR, an exception comprehensive register ESR and an error address register FAR in each macro entry in the exception vector table, and then calling a corresponding exception vector processing function; recompiling a bare computer program to obtain an elf file and a binary file; running codes of the bare computer program, and checking ELR, ESR and FAR values output by a serial port after running errors; and determining an error code according to the ELR value, determining an abnormal reason according to the ESR value, and determining an address when an access error occurs according to the FAR value. The technical problem that problem positioning is difficult to achieve after a bare computer program breaks down in the prior art is solved.

Description

Technical Field

[0001] The invention relates to the field of bare metal program problem positioning, and specifically provides a method for quickly positioning a problem after a bare metal program runs into a fault. Background Art

[0002] Bare metal programs are programs that run directly on hardware without the support of an operating system. Bare metal programs are required in many scenarios, such as hardware initialization, embedded systems, teaching and experiments, hardware debugging and testing. However, due to the lack of operating system support, bare metal programs cannot use the rich debugging methods provided by the operating system, such as ftrace, assert, and print call stack. Since bare metal programs cannot use the rich debugging methods provided by the operating system, it is difficult to locate the problem when a failure occurs without the help of hardware debugging tools.

[0003] Accordingly, there is a need in the art for a solution that can quickly locate the problem after an error occurs during the operation of a bare metal program to solve the above problem. Summary of the invention

[0004] In order to overcome the above-mentioned defects, the present invention is proposed to solve the technical problem that it is difficult to locate the problem after a bare metal program fails in the prior art.

[0005] The present invention provides a method for quickly locating a problem after a bare metal program runs fault, comprising the steps of:

[0006] Add compile option -g-O0 to bare metal programs;

[0007] Add an exception vector table of the bare metal program to the code of the bare metal program, wherein each macro entry in the exception vector table defines reading and printing the values ​​of the exception link register ELR, the exception synthesis register ESR and the error address register FAR, and then calls the corresponding exception vector processing function;

[0008] Recompile the bare metal program to obtain the elf file and binary file;

[0009] Run the bare metal program code, and after an error occurs, check the ELR, ESR, and FAR values ​​output by the serial port;

[0010] The error code is determined based on the ELR value, the cause of the exception is determined based on the ESR value, and the address at the time of the access error is determined based on the FAR value.

[0011] Further, the adding of the compilation option -g-O0 in the bare metal program includes:

[0012] Add KBUILD_CFLAGS+=-g-O0 attribute in the compilation file Makefile of the bare metal program loader.

[0013] Further, the step of adding an exception vector table of the bare metal program to the code of the bare metal program includes:

[0014] Put the address vectors of the exception vector table into general register x0,

[0015] Write the general register x0 into the system register vbar_el1 through the arm64 msr command.

[0016] Furthermore, the code for running the bare metal program checks the ELR, ESR and FAR values ​​output by the serial port after an error occurs, including

[0017] Copy the binary file to the memory of the development board;

[0018] The development board starts up and enters the uboot environment. Run the binary file of the bare metal program through the command "load mmc 0:1 0x80000000loader.bin; go0x80000000";

[0019] If a problem occurs during operation, before calling the corresponding exception vector handling function, the exception link register ELR is placed in the general register x0, the exception synthesis register ESR is placed in the general register x1, and the error address register FAR is placed in the general register x2;

[0020] The values ​​of the three general registers x0, x1 and x2 are passed as parameters to the function print_exception_register, and these three values ​​are printed out through the serial port.

[0021] Further, the step of determining the error code according to the ELR value includes:

[0022] The elf file redirects the disassembled content to the / tmp / file file by executing the command "objdump-sSd loader / loader.o> / tmp / file";

[0023] Search the / tmp / file file for the code corresponding to the value of the exception link register ELR, that is, the error code.

[0024] Further, determining the cause of the abnormality according to the ESR value includes:

[0025] Check the official arm64 documentation and determine the corresponding error type and cause based on the value of the exception comprehensive register ESR.

[0026] Working principle and beneficial effects of the present invention:

[0027] In the technical solution of the present invention, firstly, the compilation option -g-o0 is added when compiling the bare metal program, so that the elf file generated after compilation contains debugging information and prohibits compiler optimization, then the exception vector table is added to the code, and the values ​​of the exception link register ELR, the exception synthesis register ESR, and the error address register FAR are read and printed before calling each exception vector processing function, and finally the elf file corresponding to the bare metal program is parsed by objdump, and the code statement corresponding to the ELR value is found to find the erroneous code, and the official document of arm64 is checked according to the ESR value to determine the cause of the exception, and the address when the access error occurs is determined according to the FAR value, so that the erroneous code and the cause of the error can be quickly located. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The disclosure of the present invention will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present invention. In addition, similar numbers in the figures are used to represent similar components, among which:

[0029] Figure 1 The present invention is a flowchart of the main steps of a method for quickly locating a problem after a bare metal program runs fault. DETAILED DESCRIPTION

[0030] Some embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the protection scope of the present invention.

[0031] Figure 1 This is a flow chart of the main steps of a method for quickly locating a problem after a bare metal program fails to run. Figure 1 As shown, a method for quickly locating a problem after a bare metal program runs fault in this embodiment mainly includes the following steps ac.

[0032] In this embodiment, an e2000q development board is prepared with a uboot boot program, bare metal program loader code and a corresponding compilation environment. A method for quickly locating a problem after a bare metal program fails to run is implemented through the following steps ad.

[0033] Step a. Modify the code of the bare metal program loader

[0034] a1. Add the compilation option -g-O0 to the compilation file Makefile of the bare metal program loader.

[0035] Add KBUILD_CFLAGS+=-g-O0 attribute in the compilation file Makefile of the bare metal program loader, so that the compiled elf file contains debug information and prohibits the compiler from optimizing, thus retaining the original information of the bare metal program to the greatest extent and facilitating debugging.

[0036] The compilation file Makefile defines how to use the system's built-in compiler to compile the loader code and generate the final bare metal program.

[0037] In one implementation, on the one hand, it can be seen that the size of the recompiled elf file loader.o becomes larger; on the other hand, executing "readelf -a loader.o|grep debug_info" has an output similar to the following, proving that the elf file contains debug information and the compilation attribute modification is successful.

[0038] [6].debug_info PROGBITS 000000000000000000009b720

[0039] 6:0000000000000000 0SECT ION LOCAL DEFAULT 6.debug_info

[0040] a2. Add el1 exception vector table

[0041] a2.1. Add the el1 exception vector table of the bare metal program loader to the code of the bare metal program loader.

[0042] In one implementation, the address vectors of the exception vector table is first placed in the general register x0, and then the general register x0 is written into the system register vbar_el1 through the msr command provided by arm64. The implementation function is as follows:

[0043] adr x0,vectors

[0044] msr vbar_el1,x0

[0045] In one implementation, the exception vector table implements each entry according to the requirements of the arm64 architecture (the exception vector table of the arm64 architecture has 4*4, a total of 16 entries, indicating the processing function corresponding to each exception), and the exception vector table is shown below.

[0046]

[0047]

[0048] Vectors represents the address of an exception vector table. Each macro entry represents the processing of each exception, followed by the processing function for the exception (i.e., the exception vector processing function).

[0049] a2.2. Read and print system registers

[0050] Through the above-mentioned exception vector table, a macro entry is executed before calling each exception vector handling function. The macro entry defines that the values ​​of the exception link register ELR, the exception synthesis register ESR, and the error address register FAR are read and printed first, and then the corresponding exception vector handling function is called.

[0051] In one implementation, before calling the exception vector handling function, the system register ELR_el1 (exception link register) is placed into the general register x0, the system register ESR_el1 (exception summary register) is placed into the general register x1, and the system register FAR_el1 (error address register) is placed into the general register x2.

[0052] Among them, ELR refers to the exception connection register, but it includes three registers, ELR_el1, ELR_el2, and ELR_el3. Which one to use depends on the current state. The current program is a bare metal program and only runs in the el1 state, so ELR_el1 is used above. (The el1\el2\el3 running states are all designed for the arm64 hardware architecture) The same is true for the exception comprehensive register ESR and the error address register FAR.

[0053] According to the arm64 compiler principle, the values ​​of the three general registers x0, x1, and x2 will be passed as parameters to the function print_exception_register, and the three values ​​will be printed out through the serial port. The implementation function is as follows:

[0054]

[0055]

[0056] a2.3. Recompile the bare metal program loader to obtain the elf file loader.o and the binary file loader.bin.

[0057] Step b. Run the bare metal program loader code and check the serial port

[0058] b1. Copy the binary file loader.bin to the eMMC memory corresponding to the e2000q development board.

[0059] The b2.e2000q development board starts up and enters the uboot environment. Run the binary file loader.bin through the command "load mmc 0:10x80000000loader.bin; go 0x80000000".

[0060] b3. If a problem occurs during operation, before calling the corresponding exception vector processing function, the following information is printed in the serial port window through the defined macro entry, thereby obtaining the values ​​of the exception link register ELR, the exception synthesis register ESR, and the error address register FAR.

[0061] Exception occurred at PC(ELR):0x80003CE8

[0062] Exception Syndrome Register(ESR):0x96000021

[0063] Fault Address Register(FAR):0x8030015E

[0064] Step c. Locate the problem based on the above information

[0065] c1. Use objdump to parse the elf file and view the code corresponding to the value of the exception link register ELR.

[0066] The value of the exception link register ELR printed by the serial port is 0x80003CE8. The elf file loader.o redirects the disassembled content to the / tmp / file file or other files by executing the command "objdump-sSd loader / loader.o> / tmp / file". Find the code corresponding to 0x80003CE8 in the / tmp / file file.

[0067] As shown below, the machine actually requires multiple instructions to execute a code:

[0068] gicd_base=(void*)(unsignedlong)config_header->platform_info.arm.gicd_base;

[0069] 80003cd08:f0000020adrp x0,8000a000<gic_data>

[0070]

[0071] According to the ELR value 0x80003CE8, it is determined that the problem occurs in the "ldur x0, [x0, #-162]" instruction in the "gicd_base = (void*) (unsignedlong) config_header-> platform_info.arm.gicd_base;" code.

[0072] c2. The value of the exception comprehensive register ESR printed by the serial port is 0x96000021. According to the official arm64 document, the corresponding error is Data abort. The reason is Alignment. That is, when the instruction "ldur x0,[x0,#-162]" is executed, the value of [x0,#-162] is not aligned, and an alignment error occurs in the above code.

[0073] c3. The value of the error address register FAR printed by the serial port is 0x8030015E, which means that the address is currently being accessed, but the address is not 8-byte aligned, so the program runs incorrectly and reports an alignment problem.

[0074] Based on the above steps a to c, first add the compilation option -g-o0 when compiling the bare metal program, so that the elf file generated after compilation contains debugging information and prohibits compiler optimization. Then add the exception vector table in the code, read and print the values ​​of the exception link register ELR, the exception synthesis register ESR, and the error address register FAR before calling each exception vector processing function, and finally parse the elf file corresponding to the bare metal program through objdump, find the code statement corresponding to the ELR value, and find the erroneous code. According to the ESR value, check the official document of arm64 to determine the cause of the exception, and determine the address when the access error occurs according to the FAR value. In this way, the erroneous code and the cause of the error can be quickly located.

[0075] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order. They can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.

[0076] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

Claims

1. A method for quickly locating a problem after a bare metal program fails to run, characterized in that: Includes steps: Add compile option -g-O0 to bare metal programs; An exception vector table of the bare metal program is added to the code of the bare metal program. Each macro entry in the exception vector table defines reading and printing the values ​​of the exception link register ELR, the exception synthesis register ESR and the error address register FAR, and then calling the corresponding exception vector processing function; Recompile the bare metal program to obtain the elf file and binary file; Run the bare metal program code, and after an error occurs, check the ELR, ESR, and FAR values ​​output by the serial port; The error code is determined based on the ELR value, the cause of the exception is determined based on the ESR value, and the address at the time of the access error is determined based on the FAR value.

2. According to claim 1, a method for quickly locating a problem after a bare metal program fails to run, characterized in that: The adding of compile option -g-O0 in the bare metal program includes: Add KBUILD_CFLAGS+=-g-O0 attribute in the compilation file Makefile of the bare metal program loader.

3. The method for quickly locating a problem after a bare metal program fails to run according to claim 1, characterized in that: The step of adding an exception vector table of the bare metal program to the code of the bare metal program includes: Put the address vectors of the exception vector table into general register x0, Write the general register x0 into the system register vbar_el1 through the arm64 msr command.

4. The method for quickly locating a problem after a bare metal program fails to run according to claim 1, characterized in that: The code for running the bare metal program checks the ELR, ESR and FAR values ​​output by the serial port after an error occurs, including Copy the binary file to the memory of the development board; The development board starts up and enters the uboot environment. Run the binary file of the bare metal program through the command "load mmc 0:1 0x80000000loader.bin; go0x80000000"; If a problem occurs during operation, before calling the corresponding exception vector processing function, the exception link register ELR is placed in the general register x0, the exception synthesis register ESR is placed in the general register x1, and the error address register FAR is placed in the general register x2; The values ​​of the three general registers x0, x1 and x2 are passed as parameters to the function print_exception_register, and these three values ​​are printed out through the serial port.

5. The method for quickly locating a problem after a bare metal program fails to run according to claim 1, characterized in that: Determining the error code according to the ELR value includes: The elf file redirects the disassembled content to the / tmp / file file by executing the command "objdump-sSd loader / loader.o> / tmp / file"; Search the / tmp / file file for the code corresponding to the value of the exception link register ELR, that is, the error code.

6. The method for quickly locating a problem after a bare metal program fails to run according to claim 1, characterized in that: Determining the cause of the abnormality according to the ESR value includes: Check the official arm64 documentation and determine the corresponding error type and cause based on the value of the exception comprehensive register ESR.

Images