Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about the principle of the backtrace function in LiteOS, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

The execution flow of assembly instructions

Fig. 1 execution sequence of assembly instructions

As shown in figure 1 above, the assembly instruction execution of ARM is divided into three steps: fetch, decode, and execute, which is executed in a pipelined manner, that is, when running the instruction beat m, pc will point to the address of the assembly instruction Number2 to fetch the instruction, at the same time, it will translate the assembly instruction into the corresponding machine code and execute the instruction n.

Layout of stack in memory

Figure 2 layout of stack in memory

The stack layout of the LiteOS Cortex-M architecture is shown in figure 2 above. The stack interval is at the end of memory, and the stack is reduced from the end of memory (top of stack) when the program is running. The memory end of the LiteOS is the main stack space (msp_stack). The stack data of the initialization process and the interrupt function call process before the LiteOS enters the task are saved in this interval. The main stack address space goes down to the task stack space (psp_stack). The task stack space is specified when each task is created, and multiple task stack spaces are arranged in turn. A task may contain multiple functions, each with its own stack space, called stack frames. When a function is called, the stack frame of the subfunction is created, and the function is loaded into parameters, local variables, and registers. Stack frames grow from high address to low address.

Register data stack flow

In order to maintain the data in the stack, ARM designs two registers, namely fp register (framepointer, frame pointer register) and sp register (stack pointer, stack register). Fp points to the start of the stack frame of the parent function of the current function, and sp points to the top of the stack of the current function. The data content in the stack can be obtained by offsetting the address of the sp register, and the starting position of the previous stack frame can be obtained by accessing the fp register address, and then the return address of the function can be calculated. Because Cortex-M has no fp register, if you want to get the function entry address, you can only find the lr register (link register, link register, pointing to the return address of the current function) through the sp address offset, and calculate it combined with the push instruction of the function entry. The lr register is pushed into the stack at each function call to return to the position before the function call to continue execution. The function call execution process is referenced from Joseph Yiu's Cortex-M3 authoritative Guide, as shown in figure 3 below.

Figure 3 function call execution flow

As shown in the function call execution flow, after a program enters a subfunction, it usually uses the push instruction to press the value of the register into the stack, and then uses the pop instruction to unstack the register data stored in the stack and store it in the corresponding register in order. When the program executes the bl jump instruction, the value in pc is the address of the second instruction after the bl instruction, and minus the length of an assembly instruction is the address of the first instruction after bl, that is, the LR value. Before entering the Fx1, the bl or blx instruction saves the lr value to the lr register and pushes it into the stack when entering the Fx1 function. For example, there are assembly instructions as follows:

800780e: 6078 str r0, [r7, # 4] 8007810: f7ff ffe0 bl 80077d4 8007814: f7f9 fe68 bl 80014e8

When the program executes to the address 0x8007810, before the bl instruction jumps to the function test_div, the bl instruction will subtract the length of an assembly instruction from the pc address (0x8007818) at this time (here is 4), and save the calculated value 0x8007814 (this instruction is only executed to the translation, has not yet completed the entire execution process, and needs to be fetched again after returning) to the lr register.

Realization idea

According to the principle of the function call execution process, when the program jumps into an exception, the current position sp pointer is passed in, and the contents of the stack are obtained by looping self-increasing access to the sp pointer. Sp points to the top of the stack, and the boundary of the loop self-increasing is the bottom of the task stack. Because of the thum-2 instruction set used by Cortex-M, the length of assembly instructions is 2 bytes. Therefore, the assembly instruction address in the current stack can be screened out by judging whether the data in the stack is two-byte aligned and located in the code segment interval. The last instruction is calculated by judging whether the previous instruction is bl instruction or blx instruction (b, bx instruction does not stack the lr register and does not process it). The machine code composition of the jump instruction is shown in figure 4 below:

Fig. 4 composition of thum jump instruction machine code

If it is the bl instruction address (signature 0xf000), the offset address is calculated from the machine code stored in the address (see figure 5 below), thus the entry address of the jump instruction objective function is obtained. if it is the blx instruction (here is the blx register n instruction, its signature 0x4700), because the target offset address is saved in the register, the offset address cannot be calculated by the machine code. It is necessary to calculate the function entry address based on the lr address saved by the called frame until the push instruction at the entrance.

Figure 5 bl instruction offset address calculation rules

Design and implementation analysis

When an exception occurs during the operation of LiteOS, it is automatically transferred to the exception handler. LiteOS provides the backtrace function to track the stack information of the function, and calls the backtrace function through the exception handling function registered by the system to automatically print the call stack of the function when the system is abnormal.

Design ideas

Because there is no fp register in Cortex-M architecture, and the sp register is divided into msp register (for main stack) and psp register (for task stack), the function entry can only be calculated through assembly instruction machine code calculation and lr address self-increment to find the push instruction signature at the entrance of the function entrance.

Detailed design

Figure 6 backtrace code framework

When calling the ArchBackTrace API of Cortex-M architecture, the function will get the current sp pointer through ArchGetSp. If an exception occurs during initialization or interruption, sp points to msp, and sp points to psp during the task. The acquired sp pointer is passed into BackTraceWithSp for call stack analysis, and the function confirms the stack boundary through the FindSuitableStack function to find the appropriate task stack boundary or main stack boundary (no distinction between interrupt stack and initialization stack). Then the number of cyclic searches is controlled by the boundary value, which ensures that the lr addresses of all stack frames in the stack space are filtered out. Finally, the lr address is passed into the CalculateTargetAddress function to calculate the function entry address to which the previous instruction of lr (that is, jump instruction) is to be redirected.

Code path

The above code has been released in LiteOS version 5.0. the core code path is as follows:

Https://gitee.com/LiteOS/LiteOS/blob/master/arch/arm/cortex_m/src/fault.c

Backtrace effect demonstration demonstration demo

Figure 7 error use case function divided by 0

Demonstrate that demo designs a function that will cause a division error (figure 7 above). If the function is called in initialization, interrupt and task scenarios, the exception will be triggered and the corresponding information will be printed to see whether the corresponding fp (in this case, the address of the function entry, the value of the non-stack frame register) is consistent with the disassembly address of the actual code.

The backtrace function can be enabled through the menuconfig menu, with the menu item: Debug-- > Enable Backtrace. At the same time, in order to avoid the impact of compilation optimization, it is also necessary to configure the compilation optimization option to not optimize: Compiler-- > Optimize Option-- > Optimize None.

Demonstration effect

In the figure shown below, the left shows the log printed by the exception takeover, and the right shows the disassembly code. You can see the pc instruction value of the exception in the figure on the left, and the assembly code corresponding to the figure on the right is sdiv R3, R2, R3, that is, the line of int z = a / b in the test_div function. The FP value of the backtrace information printed on the left is the same as that of the function entry address in the right.

An exception is triggered during the task:

Figure 8 demonstration of the backtrace task

An exception is triggered in the interrupt handler:

Figure 9 demonstration effect of backtrace interrupt

An exception is triggered in the initialization function:

Figure 10 demonstration effect of backtrace initialization

After reading the above, do you have any further understanding of the principle of the backtrace function in LiteOS? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.