Processor, program trace method, and electronic device

Abstract

This application discloses a processor, a program tracing method, and an electronic device, belonging to the field of chip technology. The device includes: a monitoring module for monitoring and identifying function call instructions and return instructions during program execution; a storage module for sequentially recording the addresses of function call instructions and return instructions at the time of execution through a configurable-depth buffer; and an output interface for outputting the sequentially recorded addresses to an external debugging device. The sequentially recorded addresses are used by the external debugging device to obtain and map to function names, thus obtaining the function call relationships represented by function names in the program. This results in low tracing overhead and the ability to obtain tracing results containing function call semantics.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a processor, a program tracing method, and an electronic device. Background Technology

[0002] During program execution, functions form a call stack, where one function calls another, which in turn may call other functions, creating nested call relationships. This call stack reflects the program's logical flow and control flow, and is of great importance for processor debugging, performance analysis, and security analysis.

[0003] In related technologies, function call relationships are typically traced through software or hardware tracing mechanisms. Software tracing relies on compiler instrumentation, which involves inserting extra instructions into the program code to record function calls, parameter passing, and other information. This incurs additional instruction overhead and alters the program's execution flow, making it unsuitable for real-time system debugging. Hardware tracing mechanisms are more complex, recording all instructions and requiring sophisticated post-processing (such as backtracking and symbol resolution) to reconstruct the call stack. Because hardware tracing records low-level instruction-level information rather than high-level language function call relationships, the tracing results often fail to clearly represent the call semantics between functions (e.g., which function calls which function, what the call parameters are, etc.), resulting in unclear call relationships.

[0004] Therefore, how to reduce overhead and obtain more accurate and reliable tracing results during function tracing in a program is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a processor, a program tracing method, and an electronic device, which helps to reduce overhead and obtain more accurate and reliable tracing results during function tracing in a program. The technical solution is as follows.

[0006] In a first aspect, this application provides a processor, which includes: a monitoring module for monitoring and identifying function call instructions and return instructions during program execution; a storage module for orderly recording the addresses at which function call instructions and return instructions are executed through a buffer with configurable depth; and an output interface for outputting the orderly recorded addresses to an external debugging device, wherein the orderly recorded addresses are obtained by the external debugging device and mapped to function names to obtain the function call relationships represented by function names in the program.

[0007] In some possible implementations, the configurable-depth buffer includes a stack and a storage module for: pushing an entry onto the stack (a last-in, first-out stack) when the program executes a function call instruction, along with the entry address of the called function; popping an entry from the stack when the program executes a return instruction corresponding to the function call instruction; and recording the addresses corresponding to pushing or popping entries from the stack in an orderly manner.

[0008] In some possible implementations, the stack depth is N+1, the (N+1)th bit in the stack is the overflow flag, and the other bits are valid bits, where N is a positive integer. The storage module is also used to: increment the stack pointer by 1 when an entry corresponding to a function call instruction and the entry address of the called function is pushed onto the stack; decrement the stack pointer by 1 when an entry corresponding to a function call instruction is popped from the stack; and output an indication message when the pointer value is equal to N+1, which is used to indicate a stack overflow.

[0009] In some possible implementations, the storage module is also used to record the corresponding function call nesting level through the stack pointer in the stack; the output interface is also used to output the function call nesting level to an external debugging device, which uses the function call nesting level to obtain the function tracing results of the program based on the function call relationship and the function call nesting level.

[0010] In some possible implementations, the monitoring module is used to: acquire instructions executed during program execution; and identify function call instructions and return instructions based on the format of the instructions and the corresponding register usage information.

[0011] In some possible implementations, after identifying function call instructions and return instructions based on the instruction format and corresponding register usage information, the monitoring module is used to: determine that the instruction is a function call instruction if the instruction type defined in the instruction format is a first instruction type and the target register defined in the instruction is a first numbered register; and determine that the instruction is a return instruction if the instruction type defined in the instruction format is a second instruction type and the target register defined in the instruction is a second numbered register.

[0012] Secondly, a program tracing device is provided, which is applied to a debugging device. The device includes: an acquisition module for acquiring the address output by the processor being debugged, wherein the address is an address recorded in an orderly manner by the processor when executing function call instructions and return instructions during program execution; a debugging module for mapping the orderly recorded addresses to function names based on a mapping table to obtain the function call relationship represented by function names in the program, wherein the mapping table is used to describe the mapping relationship between function names and addresses; and the debugging module is also used to obtain the function tracing result of the program based on the function call relationship.

[0013] In some possible implementations, the acquisition module is also used to obtain the function call nesting level corresponding to the program; the debugging module is also used to obtain the function tracing results of the program based on the function call relationship and the function call nesting level.

[0014] Thirdly, a program tracing method is provided, characterized in that the method is applied to a processor and includes: monitoring and identifying function call instructions and return instructions during program execution; recording the addresses at which function call instructions and return instructions are executed in an ordered manner through a buffer with configurable depth; outputting the ordered recorded addresses to an external debugging device, wherein the ordered recorded addresses are used by the external debugging device to obtain and map to function names, thereby obtaining the function call relationship represented by function names in the program.

[0015] In some possible implementations, the configurable-depth buffer includes a stack. This configurable-depth buffer sequentially records the addresses of function call instructions and return instructions at the time of execution. This includes: when the program executes a function call instruction, pushing the address of the function call instruction and the entry address of the called function onto a stack (a last-in, first-out stack); when the program executes a return instruction corresponding to the function call instruction, popping the corresponding entry from the stack; and sequentially recording the addresses corresponding to the push or pop of entries from the stack.

[0016] In some possible implementations, the stack depth is N+1, the (N+1)th bit in the stack is an overflow flag, and the other bits are valid bits, where N is a positive integer. After monitoring and identifying function call instructions and return instructions, the method further includes: incrementing the stack pointer by 1 when an entry corresponding to the function call instruction and the entry address of the called function is pushed onto the stack; decrementing the stack pointer by 1 when an entry corresponding to the function call instruction is popped from the stack; and outputting an indication message when the pointer value is equal to N+1, which is used to indicate a stack overflow.

[0017] In some possible implementations, after recording the addresses of function call instructions and return instructions executed in an ordered manner through a buffer with configurable depth, the method further includes: recording the corresponding function call nesting level through a stack pointer in the stack; outputting the function call nesting level to an external debugging device, whereby the external debugging device obtains the function nesting level and obtains the function tracing results of the program based on the function call relationship and the function call nesting level.

[0018] In some possible implementations, during program execution, function call instructions and return instructions are monitored and identified, including: obtaining instructions executed during program execution; and identifying function call instructions and return instructions based on the instruction format and corresponding register usage information.

[0019] In some possible implementations, function call instructions and return instructions are identified based on the instruction format and corresponding register usage information, including: if the instruction type defined in the instruction format is a first instruction type and the target register defined in the instruction is a first numbered register, the instruction is determined to be a function call instruction; if the instruction type defined in the instruction format is a second instruction type and the target register defined in the instruction is a second numbered register, the instruction is determined to be a return instruction.

[0020] Fourthly, a program tracing method is provided, which is applied to a debugging device. The method includes: obtaining the address output by the processor being debugged, wherein the address is the address recorded in an orderly manner by the processor when executing function call instructions and return instructions during program execution; mapping the orderly recorded addresses to function names based on a mapping table to obtain the function call relationship represented by function names in the program, wherein the mapping table is used to describe the mapping relationship between function names and addresses; and obtaining the function tracing result of the program based on the function call relationship.

[0021] In some possible implementations, after obtaining the address output by the processor being debugged, the method also includes: obtaining the function call nesting level corresponding to the program; and obtaining the function tracing results of the program based on the function call relationship and the function call nesting level.

[0022] Fifthly, an electronic device is provided, which includes the processor described in the first aspect and any implementation thereof, or includes the program tracing device described in the second aspect and any implementation thereof.

[0023] In a sixth aspect, a computer device is provided, comprising a processor and a memory, wherein at least one computer program is stored in the memory, and the at least one computer program is loaded and executed by the processor to enable the computer device to implement the methods of any of the above aspects.

[0024] In a seventh aspect, a computer-readable storage medium is also provided, wherein at least one computer program is stored therein, the at least one computer program being loaded and executed by a processor to enable a computer to implement the methods of any of the above aspects.

[0025] Eighthly, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, executes the computer instructions, and causes the computer device to perform the method of any of the preceding aspects.

[0026] The technical solution provided in this application brings at least the following beneficial effects: In this application, a configurable-depth buffer is used on the processor to sequentially record address changes during the execution of function call and return instructions through hardware modules (such as a memory module). This allows for the generation of function call relationships represented by function names via a mapping method, resulting in program tracing results with function call semantics. Compared to techniques like instrumentation in the program, this application does not affect the program's execution flow, has low overhead, and the tracing results contain function call semantics, making it beneficial for use in processor debugging scenarios. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a processor provided in an embodiment of this application; Figure 4 This is a schematic diagram of a stack structure provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a program tracing device provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a program tracing method provided in an embodiment of this application; Figure 7 This is a flowchart illustrating a program tracing method provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0030] Clearly defining the function call relationships during program execution can help locate errors in processor debugging scenarios, identify hot spots or bottleneck paths in performance analysis scenarios, and detect potential security vulnerabilities (such as buffer overflows and unauthorized access) in security analysis scenarios, making it widely applicable.

[0031] However, both software and hardware tracing mechanisms have limitations. Software tracing requires additional instruction overhead (such as instrumentation overhead), making it unsuitable for real-time system debugging. Hardware tracing, on the other hand, requires complex post-processing to reconstruct the call stack. In other words, to achieve low overhead, hardware tracing often only records events without carrying semantics (i.e., no function names, no parameters, no call context, no register / stack state, etc.). This captures the program control flow, then parses the binary symbols in the control flow, and infers the call stack based on the binary symbols. The entire process is difficult to implement, and because a large amount of semantic information is lost in the control flow, the final result lacks function-level semantic relationships.

[0032] This application provides a processor. By using hardware modules (such as a storage module) on the processor, a configurable-depth buffer is used to sequentially record address changes during the execution of function call instructions and return instructions. This allows for the generation of function call relationships represented by function names through a mapping method. This achieves convenient and efficient function name-level call relationship backtracking without incurring additional overhead or affecting program execution flow.

[0033] To facilitate understanding of the technical solutions of this application, the implementation environment provided by the embodiments of this application will be described below.

[0034] For example, Figure 1 A schematic diagram of an implementation environment provided in an embodiment of this application is shown. For example... Figure 1 As shown, the implementation environment may include a first device 01 and a second device 02. The first device 01 can act as a host, and the second device 02 can be used to host the target platform.

[0035] As an example, the first device 01 can be at least one node in a physical machine, a virtualized device, an embedded device, or a computer cluster, wherein the virtualized device can be a virtual machine or a container, and the embedded device can be a development board, but is not limited thereto.

[0036] As an example, the target platform can be the platform or environment in which the program runs. For instance, the target platform can be a processor, such as a Riscv, x86, or ARM architecture processor, or it can be an embedded system (e.g., a microcontroller). The second device 02 carrying the target platform can be a physical machine, an embedded device, or at least one node in a computer cluster.

[0037] In this way, during debugging, when the program runs on the target platform, relevant information (such as the addresses of function call instructions / return instructions being executed in an ordered manner) can be captured based on the target platform's hardware capabilities. This information is transmitted to the boundary via an interface and acquired by the host. Debugging software runs on the host and stores a mapping table to record the mapping relationship between function names and addresses in the aforementioned program. The debugging software can then perform address mapping based on the acquired ordered address records to obtain an ordered function call relationship represented by function names. This allows for convenient and efficient function name-level call relationship backtracking without incurring additional overhead or affecting the program's execution flow during function tracing.

[0038] Next, an electronic device provided by an embodiment of this application will be described.

[0039] For example, Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Figure 2 As shown, the electronic device 10 may include a processor 110, a memory 120, and a communication interface 130. The processor 110 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Neural Network Processing Unit (NPU), a Tensor Processing Unit (TPU), a System on Chip (SOC), or other types of processors with data processing and / or program execution capabilities. The processor 110 may be a general-purpose processor or a special-purpose processor. The processor 110 may be deployed in the electronic device to control other components in the electronic device to perform desired functions. The processor 110 may include a register file, which may include multiple registers, such as registers X0 to X31 (X0 to X31 are register numbers), but is not limited to these.

[0040] For example, the processor 110 can, based on its own hardware capabilities, monitor and identify function call instructions and return instructions during program execution, and record the addresses at which these instructions are executed in an ordered manner. These ordered recorded addresses are transmitted to a boundary for use with external debugging devices (e.g., [missing information]). Figure 1 The host (as shown) is obtained and mapped to a function name. This facilitates obtaining program tracing results that carry function call semantics.

[0041] For example, memory 120 may include one or more forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory, which can be used as memory to provide corresponding storage space and directly exchange data with processor 110. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc., used as external storage. External storage can be used to store various applications and data, such as storing one or more computer program modules, which processor 110 can run to implement various functions of the electronic device.

[0042] For example, the communication interface 130 can be a wired interface or a wireless interface for communicating with devices under the control of the processor 110. The wired interface can be an Ethernet interface, a controller area network (CAN) interface, a local interconnect network (LIN) interface, or a FlexRay interface, while the wireless interface can be a cellular network interface or a wireless LAN interface, etc. The wired or wireless interface allows the electronic device 10 to communicate with other devices over a network to exchange data.

[0043] It should be noted that Figure 2 The structures shown are merely illustrative of the possible structures of an electronic device 10 provided in this application embodiment, and are not intended to be the sole limitation on the structure or function of the electronic device 10. In fact, the electronic device 10 can be implemented in a manner more complex than... Figure 2 The structure shown may have more or fewer components.

[0044] For example, Figure 3 A schematic diagram of a processor according to an embodiment of this application is shown. As an example, this processor can be deployed in the above-mentioned... Figure 1 The second device 02 shown serves as the target platform, or is implemented as... Figure 2 The processor 110 on the illustrated electronic device 10 is not limited to this. For example... Figure 3 As shown, the processor 300 may include a monitoring module 301, a storage module 302, and an output interface 303. The monitoring module 301, the storage module 302, and the output interface 303 will be described below.

[0045] For example, during program execution, when a function is called, a function call instruction (such as a `call` instruction) is executed. After the function finishes execution, a return instruction (such as a `ret` instruction) is executed, returning control to the caller. Therefore, in this example, the monitoring module 301 can be used to monitor and identify function call instructions and return instructions during program execution. Then, the storage module 302 can be used to sequentially record the addresses of the function call instructions and return instructions at the time of execution using a buffer with configurable depth. Subsequently, the output interface 303 can be used to output the sequentially recorded addresses to an external debugging device. The sequentially recorded addresses are used by the external debugging device to obtain and map to function names, thus obtaining the function call relationships represented by function names in the program.

[0046] This allows for program tracing results with function-level semantic relationships, revealing the nested call history between functions and facilitating more efficient processor debugging. For example, function call relationships based on function names can determine how functions that cause exceptions propagate during program execution, whether there are potential logical errors, and whether there are duplicate or unnecessary calls, thereby helping developers understand the program's execution flow, improving debugging efficiency and accuracy, and facilitating targeted performance optimization, logic verification, and error detection, among other things.

[0047] For example, one possible implementation of the monitoring module 301 is to add judgment logic for function call instructions and return instructions to the decoding unit of the processor 300 through a hardware monitoring mechanism to accurately capture function call instructions and return instructions. Thus, as an example, the monitoring module 301 can be used to obtain instructions executed during program execution, and based on the instruction format and corresponding register usage information, such as which register the instruction jumps to and which target register the return address is stored in, to identify function call instructions and return instructions.

[0048] Taking RISC-V architecture processors as an example, function call instructions in RISC-V architecture can include, but are not limited to, Jump And Link (JAL) instructions, and return instructions can include, but are not limited to, Jump And Link Register (JALR) instructions. The format of the JAL instruction can be "JAL rd, offset", where JAL is the instruction type, rd is the destination register, and offset is the offset relative to the current program counter (PC). The JAL instruction aims to call the function at PC+offset and store the return address (i.e., the address of the next instruction) in the destination register rd. The destination register rd can be numbered X1 or X5.

[0049] The JALR instruction has the format "JALR rd, offset(rs)", where JALR is the instruction type, and rs is a general-purpose register that stores the base address. Therefore, the JALR instruction aims to jump from the address pointed to by offset(rs), that is, to return from the called function (i.e., the target function), jumping to the return address stored in the target register rd. As an example, the target register rd can be the X0 register. Since the value of the X0 register is always 0, it means that the return address after the jump is not saved to any register. In other examples, the target register rd can also be other numbers; this example does not impose a unique limitation.

[0050] Subsequently, during the CPU instruction fetch and decode phase, the monitoring module 301's logic for determining whether an instruction is a function call instruction or a return instruction includes: If the instruction type defined in the instruction format matches the first instruction type and the target register defined in the instruction format is the first number register, then the instruction is determined to be a function call instruction. If the instruction type defined in the instruction format matches the second instruction type and the target register defined in the instruction format is the second number register, then the instruction is determined to be a return instruction.

[0051] For example, if the instruction type defined in the instruction format of the fetched instruction is a JAL instruction or an optional extended Zcmt instruction (i.e., the first instruction type), and the destination register (rd) number is "X1" or "X5" (i.e., the first number), then it can be determined as a call instruction. Alternatively, if the instruction type defined in the instruction format of the fetched instruction is a JALR instruction (i.e., the second instruction type), and the destination register (rd) number is X0 or another special register (i.e., the second number), then it can be determined as a ret instruction.

[0052] In this embodiment, based on the function call instructions or return instructions captured by the monitoring module 301, the storage module 302 can perform the following operations on these instructions using a buffer with configurable depth, such as a Last-In-First-Out (LIFO) stack (i.e., a call stack). When the program executes to a function call instruction, that is, when it detects that a function is to be called, the storage module 302 pushes the address of the function call instruction and the entry address of the called function into an entry on the call stack, and simultaneously uses a pointer in the call stack to indicate the nesting level of the functions.

[0053] Specifically, when a program executes a function call instruction, it can obtain the address of that instruction (i.e., the entry address of the target function). This address can be pushed onto a LIFO stack entry, indicating that a function is currently being called (i.e., the target function). Furthermore, the entry address of the target function can also be recorded; the entry address refers to the starting location of the target function in memory. Pushing this entry address onto the LIFO stack entry can be used to construct a function call chain. It's understandable that the address of the function call instruction and the function's entry address may be different addresses or the same address.

[0054] For example, in a LIFO stack structure, the first element entered is the last element retrieved, and the most recently entered element is the first element retrieved. In other words, the most recently called function finishes execution and returns first. After each function finishes execution, the monitoring module 301 listens for the corresponding return instruction (ret instruction). Therefore, the storage module 302 is also used to pop an entry corresponding to the function call instruction from the stack when the program executes the return instruction corresponding to the function call instruction, and to record the addresses corresponding to the push or pop of entries from the stack in an orderly manner, thus obtaining a complete function call chain represented by ordered address changes.

[0055] In a LIFO stack, a pointer (i.e., the stack top pointer) can be used to indicate the nesting level (i.e., the depth) of functions. The stack depth is N+1, the (N+1)th bit is the overflow flag, and the bits other than the (N+1)th bit are valid bits, where N is a positive integer. Based on this, the storage module 302 is also used to: increment the stack pointer by 1 when an entry corresponding to a function call instruction and the entry address of the called function is pushed onto the stack; and decrement the stack pointer by 1 when an entry corresponding to a function call instruction is popped from the stack. That is, the stack top pointer increases each time a function is called; and decreases each time a function returns after execution. By observing the value of the pointer in the stack, the current function call level can be determined, thus the storage module 302 can record the corresponding function call nesting level through the pointer in the stack.

[0056] For example, initialize an empty LIFO stack with pointer depth = 0. When the `call` instruction is executed, obtain the entry address `addr` of the target function, push `addr` onto the stack, and increment pointer depth by 1. When the corresponding `ret` instruction is executed, pop the top element of the stack, and decrement depth by 1.

[0057] In this way, by continuously pushing and popping from the stack, a complete function call stack can be constructed, reflecting the function call path during program execution. It is also beneficial to use the call stack to count the number of times each function is called and the time consumed.

[0058] For example, rather than limiting, the stack structure of LIFO can be as follows: Figure 4 As shown, a configurable-depth hardware stack is implemented using a circular buffer, with the depth controllable by parameters. For example, when executing a function call instruction on the target platform, the address of the captured function call instruction (call_instr_pc) and the calculated entry address of the called function (target_pc) can be stored together in an entry of the stack structure pointed to by the current pointer. Simultaneously, the LIFO stack pointer is incremented by 1 to point to the next entry. The stack structure grows downwards; initially, the stack pointer points to the top. When entry0 is pushed, the stack pointer moves from high to low memory addresses, pushing entries0 to n sequentially. The address width stored in the stack can be determined based on the address range used, thereby minimizing hardware resource usage. For example, if the system uses a 32-bit address space, call_instr_pc and target_pc can be stored in the stack with a 32-bit address width. If the system supports a larger address space (such as 64-bit), a 64-bit address width may be required to store the aforementioned addresses.

[0059] In this example, after each function completes execution and the corresponding return instruction (ret instruction) is executed, the LIFO stack pointer is decremented by 1, indicating that an entry is popped from the stack, which is the entry containing the address of the corresponding function call instruction. To minimize power consumption, the popped entry does not need to be cleared.

[0060] As an example, the pointer width of LIFO is log2(Depth) + 1, where Depth is the maximum stack capacity (e.g., 8 entries), log2(Depth) indicates how many bits are needed to represent all possible indices, and adding 1 indicates whether an overflow has occurred; that is, the highest bit indicates whether the LIFO stack has overflowed. Therefore, the storage module 302 is also used to output indication information when the pointer value equals N+1 (i.e., log2(Depth) + 1 indicates overflow). This indication information is used to indicate the current stack overflow. This overflow detection can avoid problems such as erroneous jumps, performance degradation, and security risks.

[0061] For example, after obtaining the addresses of the function call instructions and return instructions in an orderly manner during program execution based on the stack described above, the output interface 303 can be used to output the orderly recorded addresses, function call nesting levels, etc. to an external debugging device.

[0062] Specifically, the addresses, function call nesting levels, and other information recorded in the stack are output to the boundary (e.g., the debug interface) for external debugging devices to access. This boundary can be understood as the communication channel between the hardware and the debug interface, such as the Joint Test Action Group (JTAG) interface, debug registers, or a performance monitoring unit (PMU), but is not limited to these.

[0063] As an example, embodiments of this application also provide a program tracing device. See also... Figure 5 , Figure 5 The diagram shown is a structural schematic of a program tracing device provided in an embodiment of this application. This program tracing device can be applied to external debugging equipment. Figure 5 As shown, the program tracing device 500 may include an acquisition module 501 and a debugging module 502. The acquisition module 501 and the debugging module 502 can be implemented as functional modules of debugging software, but are not limited thereto. In this example, on an external debugging device, the acquisition module 501 can acquire information transmitted from the processor 300, such as the addresses of the ordered records mentioned above, and may also include the nested function call hierarchy.

[0064] Next, the debugging module 502 can map the ordered recorded addresses to function names based on the mapping table, thereby obtaining the function call relationship represented by function names in the program. The mapping table describes the mapping relationship between function names and addresses. Specifically, the debugging module 502 can map the addresses of the acquired function call instructions to the function entry addresses based on the mapping table, thus dynamically and in real-time reflecting the program body and function call history currently being executed by the processor 300 within the Integrated Development Environment (IDE).

[0065] In this example, the debugging module 502 can access these addresses obtained from the processor 300 through a debugger (such as GDB, Visual Studio Debugger, LLDB, etc.), but these addresses are physical or virtual addresses in the machine code and cannot be directly mapped to function names in the source code. Therefore, the debugging module 502 can use a debugger to load a mapping table in the form of the program's symbol table or debugging information (such as DWARF, PDB files) to achieve the mapping from address to function name.

[0066] For example, address 0x400500 corresponds to the function `main()`, and address 0x400600 corresponds to the function `foo()`. As an example, the mapping between addresses and function names can be pre-built into an index structure before program tracing, allowing for quick indexing of function names when the address of a called function is known.

[0067] Furthermore, in an integrated development environment (IDE), the debugger can display these mapped function names as a call stack. Users can see the currently executing function and its call chain (e.g., main()->foo()->bar()), with a nesting level of 3.

[0068] In this way, as the debugger continuously obtains the addresses of the program's call stack from the processor 300 in an ordered manner, it can reflect the program's execution status in real time. In complex scenarios such as debugging multithreading, asynchronous tasks, and interrupt handling, it can help developers locate problems. If the program crashes, it can also display the function call path that caused the crash, helping to quickly locate the source of the error.

[0069] This embodiment achieves function name-level call relationship backtracking without affecting program execution. Compared to related technologies that rely on compiler instrumentation for function tracing, this embodiment achieves function call tracing with virtually zero performance loss and no additional instruction overhead. Furthermore, unlike methods that require post-processing to rebuild the call stack, the call stack obtained in this embodiment directly records function-level semantic relationships, which helps improve processor debugging efficiency. In addition, this embodiment can serve as a lightweight hardware solution, achieving function name-level call relationship presentation with minimal hardware resources, making it easy to implement and cost-effective.

[0070] Based on the same technical concept as the processor provided in the above-described embodiments of this application, this embodiment also provides a program tracing method.

[0071] For example, Figure 6 A flowchart illustrating a program tracing method provided in an embodiment of this application is shown. This method can be implemented on a processor, such as... Figure 3 It executes on the processor 300 shown, but is not limited to this. For example... Figure 6 As shown, this method may include steps S510 to S530.

[0072] The S510 monitors and identifies function call instructions and return instructions during program execution.

[0073] The S520 uses a configurable-depth buffer to record the addresses at which function call instructions and return instructions are executed in an ordered manner.

[0074] S530 outputs the ordered recorded addresses to an external debugging device. The ordered recorded addresses are used by the external debugging device to obtain and map to function names, thereby obtaining the function call relationship represented by function names in the program.

[0075] In some possible implementations, S510 may specifically include the following sub-steps: obtaining the instructions executed during program execution; identifying function call instructions and return instructions based on the instruction format and corresponding register usage information.

[0076] In some possible implementations, the function call instruction and return instruction can be identified based on the instruction format and corresponding register usage information. This may include: if the instruction type defined in the instruction format is a first instruction type and the target register defined in the instruction is a first numbered register, the instruction is determined to be a function call instruction; if the instruction type defined in the instruction format is a second instruction type and the target register defined in the instruction is a second numbered register, the instruction is determined to be a return instruction.

[0077] In some possible implementations, the configurable-depth buffer includes a stack. With a configurable-depth buffer, in S520, the orderly recording of the addresses when function call instructions and return instructions are executed may include: when the program executes a function call instruction, pushing the address of the function call instruction and the entry address of the called function onto an entry on the stack, where the stack is a last-in-first-out stack; when the program executes the return instruction corresponding to the function call instruction, popping an entry corresponding to the function call instruction from the stack; and orderly recording the addresses corresponding to the push or pop of entries from the stack.

[0078] In some possible implementations, the stack depth is N+1, the N+1th bit in the stack is the overflow flag, and the other bits are valid bits, where N is a positive integer. After S510, this method also includes: when pushing an entry containing the address of the function call instruction and the entry address of the called function onto the stack, incrementing the stack pointer by 1; when popping an entry corresponding to the function call instruction from the stack, decrementing the stack pointer by 1; and when the pointer value is equal to N+1, outputting an indication message to indicate a stack overflow.

[0079] In some possible implementations, after recording the addresses of function call instructions and return instructions executed in an ordered manner through a buffer with configurable depth, the method further includes: recording the corresponding function call nesting level through a stack pointer in the stack; outputting the function call nesting level to an external debugging device, whereby the external debugging device obtains the function nesting level and obtains the function tracing results of the program based on the function call relationship and the function call nesting level.

[0080] It should be noted that, for information regarding the function or beneficial effects of each step in the above-mentioned program tracing method, please refer to the relevant description of the processor in the foregoing embodiments, which will not be repeated here.

[0081] Based on the same technical concept as the above-mentioned program tracing device, this embodiment also provides a program tracing method.

[0082] For example, Figure 7 A flowchart illustrating a program tracing method provided in an embodiment of this application is shown. This method can be applied to external debugging devices, but is not limited thereto. Figure 7 As shown, this method may include steps S610 to S630.

[0083] S610, obtain the address output by the processor being debugged. The address is the address that the processor records in an orderly manner when executing function call instructions and return instructions during program execution. S620: Based on the mapping table, the addresses recorded in an ordered manner are mapped to function names respectively, so as to obtain the function call relationship represented by function names in the program. The mapping table is used to describe the mapping relationship between function names and addresses. S630 obtains the function tracing results of the program based on function call relationships.

[0084] In some possible implementations, after obtaining the address output by the processor being debugged, the method also includes: obtaining the function call nesting level corresponding to the program; and obtaining the function tracing results of the program based on the function call relationship and the function call nesting level.

[0085] It should be noted that, for information regarding the function or beneficial effects of each step in the above-mentioned program tracing method, please refer to the relevant description of the program tracing device in the foregoing embodiments, which will not be repeated here.

[0086] In an exemplary embodiment, a computer device is also provided, comprising a processor and a memory, wherein at least one computer program is stored in the memory. The at least one computer program is loaded and executed by one or more processors to enable the computer device to implement any of the methods described above.

[0087] In an exemplary embodiment, a computer-readable storage medium is also provided, storing at least one computer program. This at least one computer program is loaded and executed by a processor of a computer device to enable the computer to implement any of the methods described above. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, or an optical data storage device, etc.

[0088] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the methods described above.

[0089] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the calibration data involved in this application were all obtained under fully authorized conditions.

[0090] It should be understood that "multiple" as used in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0091] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A processor, characterized in that, The processor includes: The monitoring module is used to monitor and identify function call instructions and return instructions during program execution; The storage module is used to record the addresses at which the function call instructions and the return instructions are executed in an ordered manner through a buffer with a configurable depth; An output interface is used to output the address of the ordered record to an external debugging device. The address of the ordered record is used by the external debugging device to obtain and map to a function name, thereby obtaining the function call relationship represented by the function name in the program.

2. The processor according to claim 1, characterized in that, The configurable depth buffer includes a stack, and the storage module is used for: When the program executes the function call instruction, the address of the function call instruction and the entry address of the called function are pushed onto an entry in the stack, where the stack is a last-in-first-out stack. If the program executes to the return instruction corresponding to the function call instruction, an entry corresponding to the function call instruction is popped from the stack; Record the addresses corresponding to when an entry is pushed onto or popped from the stack in an orderly manner.

3. The processor according to claim 2, characterized in that, The stack has a depth of N+1, the (N+1)th bit in the stack is an overflow flag, and the other bits are valid bits, where N is a positive integer. The storage module is also used for: When the address of the function call instruction and the entry address of the called function are pushed onto an entry in the stack, the stack pointer is incremented by 1; When an entry corresponding to the function call instruction is popped from the stack, the stack pointer is decremented by 1; If the value of the pointer is equal to N+1, output an indication message, which is used to indicate the stack overflow.

4. The processor according to claim 2 or 3, characterized in that, The storage module is also used to record the corresponding function call nesting level through pointers in the stack; The output interface is also used to output the function call nesting level to the external debugging device. The function call nesting level is used by the external debugging device to obtain the function tracing results of the program based on the function call relationship and the function call nesting level.

5. The processor according to any one of claims 1-3, characterized in that, The monitoring module is used for: Obtain the instructions executed during the program's execution; Based on the format of the instruction and the corresponding register usage information, the function call instruction and the return instruction are identified.

6. The processor according to claim 5, characterized in that, Based on the format of the instruction and the corresponding register usage information, the monitoring module identifies the function call instruction and the return instruction. The monitoring module is used to: If the instruction type defined in the format of the instruction is the first instruction type, and the target register defined in the instruction is the first number register, then the instruction is determined to be the function call instruction; If the instruction type defined in the instruction format is the second instruction type, and the target register defined in the instruction is the second number register, then the instruction is determined to be the return instruction.

7. A program tracing method, characterized in that, The method is applied to a processor, and the method includes: During program execution, monitor and identify function call instructions and return instructions; The addresses at which the function call instructions and the return instructions are executed are recorded in an orderly manner through a buffer with configurable depth. The address of the ordered record is output to an external debugging device. The address of the ordered record is used by the external debugging device to obtain and map to a function name, thereby obtaining the function call relationship represented by the function name in the program.

8. The method according to claim 7, characterized in that, The configurable-depth buffer includes a stack, and the orderly recording of the addresses at which the function call instructions and the return instructions are executed via the configurable-depth buffer includes: When the program executes the function call instruction, the address of the function call instruction and the entry address of the called function are pushed onto an entry in the stack, where the stack is a last-in-first-out stack. If the program executes to the return instruction corresponding to the function call instruction, an entry corresponding to the function call instruction is popped from the stack; Record the addresses corresponding to when an entry is pushed onto or popped from the stack in an orderly manner.

9. The method according to claim 8, characterized in that, The stack has a depth of N+1, the (N+1)th bit in the stack is an overflow flag, and the other bits are valid bits, where N is a positive integer. After monitoring and identifying function call instructions and return instructions, the method further includes: When the address of the function call instruction and the entry address of the called function are pushed onto an entry in the stack, the stack pointer is incremented by 1; When an entry corresponding to the function call instruction is popped from the stack, the stack pointer is decremented by 1; If the value of the pointer is equal to N+1, output an indication message, which is used to indicate the stack overflow.

10. The method according to claim 8 or 9, characterized in that, After sequentially recording the addresses at which the function call instructions and the return instructions were executed using a buffer of configurable depth, the method further includes: The corresponding function call nesting level is recorded using pointers in the stack; The function call nesting level is output to an external debugging device. The function nesting level is used by the external debugging device to obtain the function tracing results of the program based on the function call relationship and the function call nesting level.

11. The method according to any one of claims 7-9, characterized in that, The monitoring and identification of function call instructions and return instructions during program execution includes: Obtain the instructions executed during the program's execution; Based on the format of the instruction and the corresponding register usage information, the function call instruction and the return instruction are identified.

12. The method according to claim 11, characterized in that, Based on the format of the instruction and the corresponding register usage information, the function call instruction and the return instruction are identified, including: If the instruction type defined in the format of the instruction is the first instruction type, and the target register defined in the instruction is the first number register, then the instruction is determined to be the function call instruction; If the instruction type defined in the instruction format is the second instruction type, and the target register defined in the instruction is the second number register, then the instruction is determined to be the return instruction.

13. An electronic device, characterized in that, The electronic device includes the processor as described in any one of claims 1-6.

Images