Debugging analysis system and method in embedded system software development scenario, electronic device and storage medium

Abstract

The application discloses a debugging analysis system and method in an embedded system software development scenario, an electronic device and a storage medium, and relates to the technical field of embedded system software development. The debugging analysis system comprises a virtual machine module, a cache simulator, a bus simulator, a memory legality analyzer, a function dynamic tracking module, a performance sampling module, an on-chip simulation module, a debugging server module and a script interpretation and execution module. The script interpretation and execution module can send control commands to the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip simulation module and the debugging server. The debugging analysis system and method in the embedded system software development scenario, the electronic device and the storage medium provided by the application can reduce the workload of embedded system software debugging.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of electronic information technology, and relates to a debugging analysis system, in particular to a debugging analysis system and method in the development scenario of embedded system software, an electronic device and a storage medium. BACKGROUND

[0002] With the rapid development of the Internet of Things ecology, more and more functions are integrated in a single MCU. Due to the independence of embedded chips, plus the fact that resources are relatively scarce, the debugging process is not as convenient as on the Linux / Unix / Windows platform; in addition, due to the increasing size of embedded software and the large difference in the level of developers, software debugging on the embedded platform becomes very difficult.

[0003] In the existing embedded debugging means, a large number of R&D personnel still analyze and locate problems by adding print logs, which is time-consuming and inefficient; or directly debug on-chip through JTAG, but the chip resources are limited, and it is relatively difficult to realize complete tracking and debugging of the system at runtime.

[0004] Therefore, there is an urgent need to design a new system debugging and analysis method to overcome at least some of the above-mentioned deficiencies of the existing system debugging and analysis method. SUMMARY

[0005] The present application provides a debugging analysis system and method in the development scenario of embedded system software, an electronic device and a storage medium, which can reduce the workload of embedded system software debugging.

[0006] To solve the above technical problems, according to one aspect of the present application, the following technical solution is adopted:

[0007] A debugging analysis system in the development scenario of embedded system software, the debugging analysis system comprising: a virtual machine module, a cache simulator, a bus simulator, a memory legality analyzer, a function dynamic tracking module, a performance sampling module, an on-chip simulation module, a debugging server module and a script interpretation and execution module;

[0008] The script interpretation and execution module is connected to the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip simulation module and the debugging server, and can send control commands to the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip simulation module and the debugging server;

[0009] The virtual machine module is connected to the bus simulator, the memory legality analyzer, the performance sampling module, the on-chip simulation module and the debugging server module to simulate CPU execution of program instructions;

[0010] The cache simulator is connected to the memory legitimacy analyzer, the function dynamic tracking module, and the performance sampling module respectively to simulate cache hits, replacement strategies, and calculate miss rates;

[0011] The bus simulator is connected to the memory legitimacy analyzer and the function dynamic tracking module respectively to simulate CPU bus access;

[0012] The memory legitimacy analyzer is used to check the legitimacy of CPU bus access, and the legitimacy of the memory is dynamically adjusted when the program is running;

[0013] The function dynamic tracking module is used to monitor the set function call;

[0014] The performance sampling module is used to obtain parameters representing performance;

[0015] The on-chip simulation module is used to connect to the physical chip and cooperate with the virtual machine module to enable a set number of hardware breakpoints on the physical chip;

[0016] The debugging server module is connected to the debugger to receive and respond to control requests from the debugger.

[0017] As an embodiment of the present invention, the cache simulator includes a cache simulator and / or a TLB simulator;

[0018] The cache simulator is used to simulate hardware cache hit and replacement strategies and to calculate cache miss rates;

[0019] The TLB simulator is used to simulate the hardware page table cache hit and replacement strategy, and is used to count the TLB miss rate.

[0020] As an embodiment of the present invention, the performance sampling module is used to collect cache, TLB, and function call events, or sample the program status on the virtual machine module at a fixed frequency, count the number of cache and TLB misses, the proportion of function execution time, the function call stack and call parameters, and analyze the performance of the software;

[0021] The on-chip simulation module is used to connect to the physical chip under the set debugging scenario, and cooperate with the virtual machine module to enable unlimited hardware breakpoints on the physical chip; setting breakpoints on the flash is similar to software breakpoints, and the code at the breakpoint in the flash will be directly replaced with the breakpoint instruction, and the original instruction will be recorded in the tool; when the physical CPU executes the breakpoint instruction in the flash, a breakpoint exception will be generated, and the tool will capture the exception. At this time, the virtual machine module will take over the context state of the physical processor, execute the original instruction at the breakpoint position, and write the instruction result back to the physical processor; or a real peripheral of the chip can be mounted on the bus simulator to achieve the purpose of the virtual machine module operating the real peripheral.

[0022] As an embodiment of the present invention, the virtual machine module includes an input part, an arithmetic unit, a controller, an output part and a general register;

[0023] RAM, ROM, and virtual interrupt controller are registered on the bus simulator, which is responsible for distributing CPU access to different components;

[0024] The function dynamic tracking module is used to replace the function entry instruction to interrupt the normal operation of the virtual machine module, so that the outside of the virtual machine module can perceive it, thereby controlling the actual execution logic of the function; the function dynamic tracking module is used for performance analysis and simulation of the underlying device.

[0025] According to another aspect of the present invention, the following technical solution is adopted: a debugging and analysis method in an embedded system software development scenario, the debugging and analysis method comprising:

[0026] The virtual machine module simulates the CPU to execute program instructions;

[0027] The cache simulator simulates cache hits and replacement strategies and calculates miss rates;

[0028] The bus simulator simulates CPU bus access;

[0029] The memory legitimacy analyzer checks the legitimacy of CPU bus accesses, and the legitimacy of memory is dynamically adjusted while the program is running;

[0030] The function dynamic tracking module monitors the set function calls;

[0031] The performance sampling module obtains parameters that characterize performance;

[0032] The on-chip simulation module and the virtual machine module work together to enable a set number of hardware breakpoints on the physical chip;

[0033] The debug server module receives and responds to control requests from the debugger;

[0034] The script interpretation and execution module communicates with the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server respectively, and can send control commands to the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server.

[0035] As an embodiment of the present invention, the cache simulator includes a cache simulator and / or a TLB simulator;

[0036] The cache simulator simulates the hardware cache hit and replacement strategy to calculate the cache miss rate;

[0037] The TLB simulator simulates the hardware page table cache hit and replacement strategy to calculate the TLB miss rate.

[0038] As an embodiment of the present invention, the performance sampling module collects cache, TLB, and function call events, or samples the program status on the virtual machine module at a fixed frequency, counts the number of cache and TLB misses, the proportion of function execution time, the function call stack and call parameters, and analyzes the performance of the software;

[0039] The on-chip simulation module is connected to the physical chip under the set debugging scenario, and cooperates with the virtual machine module to enable unlimited hardware breakpoints on the physical chip; setting breakpoints on the flash is similar to software breakpoints, and the code at the breakpoint in the flash will be directly replaced with the breakpoint instruction, and the original instruction will be recorded in the tool; when the physical CPU executes the breakpoint instruction in the flash, a breakpoint exception will be generated, and the tool will capture the exception. At this time, the virtual machine module will take over the context state of the physical processor, execute the original instruction at the breakpoint position, and write the instruction result back to the physical processor; or a real peripheral of the chip can be mounted on the bus simulator to achieve the purpose of the virtual machine module operating the real peripheral.

[0040] As an embodiment of the present invention, the function dynamic tracing module replaces the function entry instruction to interrupt the normal operation of the virtual machine module, so that the outside of the virtual machine module can perceive it, thereby controlling the actual execution logic of the function; the function dynamic tracing module is used for performance analysis and simulation of the underlying device.

[0041] According to another aspect of the present invention, the following technical solution is adopted: an electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0042] According to another aspect of the present invention, the following technical solution is adopted: a storage medium stores computer program instructions, and the computer program instructions implement the steps of the above method when executed by a processor.

[0043] The beneficial effect of the present invention is that the debugging and analysis system, method, electronic device and storage medium in the embedded system software development scenario proposed by the present invention can reduce the workload of embedded system software debugging.

[0044] The present invention can shield the functions of the underlying hardware from embedded software developers, allowing developers to debug their business functions without going through the hardware; through the memory legitimacy analyzer, function dynamic tracking module, script interpretation and execution module and other functions of the debugging and analysis system provided by the present invention, software problems can be quickly located and solved in the product development stage; when finally debugging with the hardware, the workload of most software debugging can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 Schematic diagram of the composition of the debugging system for existing embedded software analysis.

[0046] Figure 2 FIG. 1 is a schematic diagram of the composition of an analysis and debugging system in one embodiment of the present invention.

[0047] Figure 3 FIG. 1 is a schematic diagram of the composition of an electronic device in one embodiment of the present invention. DETAILED DESCRIPTION

[0048] The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0049] In order to further understand the present invention, preferred embodiments of the present invention are described below in conjunction with examples. However, it should be understood that these descriptions are only for further illustrating the features and advantages of the present invention, rather than limiting the claims of the present invention.

[0050] The description in this section is only for several typical embodiments, and the present invention is not limited to the scope of the embodiments described. The same or similar existing technical means and some technical features of the embodiments are mutually replaced within the scope of the description and protection of the present invention.

[0051] The description of the steps in each embodiment in the specification is only for the convenience of explanation, and the implementation method of this application is not limited by the order of implementation of the steps.

[0052] The term “connection” in the specification includes both direct connection and indirect connection.

[0053] The present invention discloses a debugging and analysis system for embedded system software development scenarios. Figure 2This is a schematic diagram of the composition of the analysis and debugging system in one embodiment of the present invention; please refer to Figure 2 The debugging and analysis system includes: a virtual machine module 1, a cache simulator 2, a bus simulator 3, a memory legitimacy analyzer 4, a function dynamic tracking module 5, a performance sampling module 6, an on-chip simulation module 7, a debugging server module 8 and a script interpretation and execution module 9.

[0054] The script interpretation and execution module 9 is respectively connected to the virtual machine module 1, memory legitimacy analyzer 4, function dynamic tracing module 5, performance sampling module 6, on-chip simulation module 7 and debugging server 8, and can send control commands to the virtual machine module 1, memory legitimacy analyzer 4, function dynamic tracing module 5, performance sampling module 6, on-chip simulation module 7 and debugging server 8.

[0055] The virtual machine module 1 is connected to the bus simulator 3, memory legitimacy analyzer 4, performance sampling module 6, on-chip simulation module 7, and debug server module 8 to simulate the CPU executing program instructions. In one embodiment of the present invention, the virtual machine module 1 internally includes an input unit, an arithmetic unit, a controller, an output unit, and general registers.

[0056] The cache simulator 2 is connected to the memory legitimacy analyzer 4, the function dynamic tracking module 5, and the performance sampling module 6, respectively, to simulate cache hits and replacement strategies and calculate miss rates. In one embodiment of the present invention, the cache simulator 2 includes a cache simulator and / or a TLB simulator; the cache simulator is used to simulate hardware cache hits and replacement strategies to calculate cache miss rates; the TLB simulator is used to simulate hardware page table cache hits and replacement strategies to calculate TLB miss rates.

[0057] The bus simulator 3 is connected to the memory validity analyzer 4 and the function dynamic tracking module 5 to simulate CPU bus access. RAM, ROM, and virtual interrupt controller are registered on the bus simulator, which is responsible for distributing CPU access to different components.

[0058] The memory validity analyzer 4 is used to check the validity of CPU bus access. The validity of memory is dynamically adjusted during program execution. For example, after mallocing a section of memory, the memory is valid, but after freeing it, the memory is invalid. This part can dynamically analyze the heap and stack.

[0059] The function dynamic tracking module 5 is used to monitor the set function call. In one use scenario of the application, the principle of the function dynamic tracking module 5 is to replace the instruction of the function entry with a special instruction, which can interrupt the normal operation of the virtual machine module, so that the virtual machine outside can be perceived, thereby the real execution logic of the function can be controlled, and the module is commonly used for performance analysis and simulation of the underlying device.

[0060] The performance sampling module 6 is used to obtain parameters representing performance. In one embodiment of the application, the performance sampling module 6 is used to collect Cache, TLB, function call events, or sample the program state on the virtual machine module at a certain fixed frequency, count the Cache, TLB miss times, function execution time proportion, function call stack and call parameters, and analyze the performance of the software.

[0061] The on-chip simulation module 7 is used to connect the physical chip 11 and cooperate with the virtual machine module to enable a set number of hardware breakpoints on the physical chip 11. In some special debugging scenarios, the module connects the physical chip through JTAG and cooperates with the virtual machine to enable an unlimited number of hardware breakpoints on the chip. The specific method is to replace the code at the breakpoint of the flash with a breakpoint instruction similar to the software breakpoint, and record the original instruction in the tool. When the physical CPU executes to the breakpoint instruction of the flash, a breakpoint exception is generated, and the tool captures the exception. Because the tool has a virtual processor, the virtual processor takes over the context state of the physical processor at this time, executes the original instruction at the breakpoint position, and writes the instruction result back to the physical processor. A real peripheral of the chip can also be mounted to the virtual bus to achieve the purpose that the virtual machine can operate the real peripheral.

[0062] The debugging server module 8 is connected to the debugger 10 and is used to receive and respond to the control request of the debugger 10. The debugger 10 can be a common third-party debugger (such as GDB, LLDB).

[0063] The application also discloses a debugging analysis method in an embedded system software development scene, and the debugging analysis method comprises the following steps of:

[0064] The virtual machine module simulates the CPU to execute program instructions;

[0065] The cache simulator simulates cache hit and replacement strategy, and counts the missing rate;

[0066] The bus simulator simulates the CPU bus access;

[0067] The memory legality analyzer checks the legality of the CPU bus access, and the legality of the memory is dynamically adjusted during the program running;

[0068] The function dynamic tracking module monitors the set function calls;

[0069] The performance sampling module obtains parameters that characterize performance;

[0070] The on-chip simulation module and the virtual machine module work together to enable a set number of hardware breakpoints on the physical chip;

[0071] The debug server module receives and responds to control requests from the debugger;

[0072] The script interpretation and execution module communicates with the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server respectively, and can send control commands to the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server.

[0073] In one application scenario, the debugging and analysis method for embedded system software development involves the following workflow: The script interpretation and execution module first runs, parsing incoming parameters, including the ELF file to be debugged and the function hook configuration script file. The former is used to initialize the virtual CPU module, virtual bus module, and TLB / Cache module, while the latter is used to initialize the function dynamic tracking module and the memory legitimacy analysis module.

[0074] After initialization is complete, the virtual CPU will fetch instructions from the entry point address described in the ELF file. These instructions include arithmetic instructions and memory access instructions. All memory accesses are subject to a memory access validity check module. Initially, all memory areas are marked as "illegal." Then, the global variable and heap initialization functions are hooked. These two functions initialize the "illegal" memory space. After initialization is complete, the corresponding memory address is marked as "legal," and subsequent CPU access can proceed normally.

[0075] The debugging and analysis system hooks the Malloc and Free functions. Before Malloc returns, it marks the allocated memory address space as "valid." Before Free returns, it re-marks the freed memory address as "illegal." This ensures that heap memory accesses are effectively checked. Similar validation methods can be used for stack pushes and pops.

[0076] When the performance sampling module is enabled, cache / TLB miss rates can be counted. The script interpreter execution module can also track which function calls are tracked, along with their time consumption. The performance sampling module can also interrupt the virtual CPU at a fixed frequency, such as 997Hz, to record the current virtual CPU's PC register contents and the stack call history. Ultimately, the number of times a sampling point falls within a particular function during a specific period can be calculated, reflecting the proportion of the total sampling time consumed by that function.

[0077] Developers can flexibly control all components of the scripted execution environment through script interpretation. For example, they can hook an ELF function into a function in a script. If a developer hooks function A, when the virtual CPU executes function A, the script's hook for function A will actually execute. The actual code in function A will be executed by the script and the result will be returned to the virtual CPU. To the virtual CPU, function A will execute normally and return. However, to function A, its actual behavior is specified by the hook in the script.

[0078] When the debug server component is enabled, an external debugger (such as GDB, LLDG, etc.) can be connected to the debug analysis system. This allows developers to debug program code through GDB and perform operations such as single-stepping, printing call stacks, setting breakpoints, and watchpoints.

[0079] During the early stages of project development and debugging, users can directly add customized business code to the chip manufacturer's SDK. The resulting ELF file is loaded into the tool's sandbox environment for direct execution by the virtual CPU. Before running the code, the sandbox hooks SDK hardware-related function calls, emulating functionality through software rather than hardware behavior.

[0080] The tool also supports user-defined scripts. Through the scripts, customers can hook the functions they want at will, track the call stack when the function is called, statistics on function execution time, inject and execute arbitrary code, etc., providing a very flexible and extensible interface to meet customers' flexible debugging needs.

[0081] Programs running in the sandbox environment are identical to those running on a physical chip. The only difference is that while loading the program instructions from the ELF file into the sandbox, the tool uses a dynamic tracing module to hook hardware driver functions that interact with the underlying hardware into the script execution environment. When the application code calls the hooked function, the script execution environment takes over, emulating the hardware functionality and returning meaningful results. This approach shields the application layer from underlying differences. For example, in a Wi-Fi chip, the application layer uses a socket to connect to the network. The socket interface coordinates the TCP / IP and 802.11 protocol stacks to send and receive data packets. In a sandbox environment, without the 802.11 protocol stack and underlying hardware, the tool can directly call the socket interface of the operating system running the tool to complete TCP / IP data exchange by hooking the socket interface.

[0082] During embedded debugging, memory-related issues such as memory leaks, out-of-bounds access, use of freed memory, and stack overflows are common. This debugging and analysis system checks every memory access to verify its legality. Through the dynamic function tracking module, the malloc and free functions can be hooked. When malloc successfully allocates memory, the allocated memory block is marked as "legal," allowing subsequent virtual CPU access to the area to proceed normally. When a block of memory is freed through the free interface, the corresponding memory area is marked as "illegal," and the virtual CPU will report an exception. This allows the virtual CPU to locate issues such as illegal heap memory access, out-of-bounds access, and use of freed memory space. The stack area can be monitored by monitoring the virtual CPU's stack top register (SP). When a function pushes the stack, the stack top register (SP) is checked to see if it exceeds the current thread's maximum stack address, marking the stack frame space as "legal." After the function returns, the area popped from the stack top register (SP) is marked as "illegal," allowing subsequent references to illegal local variables to be detected.

[0083] The performance sampling module, through the function dynamic tracking module, can also implement dynamic tracking and sampling of specified functions. When developers want to see when a function is called and by whom, they can dynamically track the function. Specifically, by setting the function's first address to "illegal," when the virtual CPU fetches instructions from that address, a corresponding event is triggered. In the event handling function, the function call stack and function calling thread can be obtained. If the function return address is modified to an illegal address value in the event handling function, an event is also triggered when the function returns. By comparing the times of the two events, the function's runtime can be determined.

[0084] The performance sampling module can also interrupt the virtual CPU at a fixed frequency. Each interruption is called a sampling point. When the virtual CPU is interrupted, the CPU's instruction counter (PC), return address register (RA), top of stack register (SP), and the function call chain on the current stack are recorded. When sampling stops, the recorded function call chains are merged and organized to generate the percentage of the sampled function execution time in the total sampling time, which can intuitively reflect the program execution status during this period.

[0085] The debug server module receives control requests from debuggers, such as GDB and LLDB. The debugger can operate in client-side debugging mode, with the debug analysis system acting as the server and the debugger as the client. While running, the debug analysis system responds to debugger connection requests. Once connected, the debugger can control the virtual CPU, including running, pausing, single-stepping, printing variables, reading and writing memory, printing the function call stack, and setting breakpoints and watchpoints.

[0086] The on-chip debugging function connects to the physical chip via the JTAG physical interface provided by the emulator. JTAG provides real hardware access to the virtual CPU. When the virtual CPU and the physical CPU are running the same program code, the debugging and analysis system can enter on-chip debugging (on-chip debug) mode. The GDB debugger can be connected to this debugging system, which in turn connects to the physical CPU to control the physical CPU's operations, such as running, pausing, single-stepping, printing variables, reading and writing memory, printing the function call stack, and setting breakpoints and watchpoints. Because of the virtual CPU, an unlimited number of breakpoints can be implemented on the physical chip. Specifically, when the debugging and analysis system receives a breakpoint instruction from the GDB debugger, it directly controls the CPU via JTAG to modify the Flash code corresponding to the breakpoint address, replacing the function instruction at the address with the "breakpoint instruction." When the physical CPU executes the breakpoint instruction, the debugging and analysis system obtains the general register context of the breakpoint instruction via JTAG and loads it into the virtual CPU. The virtual CPU then executes the actual instruction at the breakpoint address and writes the instruction result back to the corresponding registers of the physical CPU, resuming program execution.

[0087] When the virtual CPU and the physical CPU are running different code, the debugging and analysis system can be put into virtual CPU mode. Auxiliary instructions can be downloaded to the physical CPU via JTAG. The virtual CPU then interacts with the physical CPU's auxiliary program via JTAG, enabling real access to physical peripherals. The auxiliary program can redirect interrupts and other information to the virtual CPU.

[0088] The script execution environment provides developers with an advanced configuration interface. Through the Lua scripting language, developers can flexibly control each component of this debugging and analysis system, such as hooking any function to execute custom code; or docking the host system's devices into the application. For example, the Bluetooth operation interface of the chip SDK will be called in the embedded ELF program. In the virtual environment, the LinuxHost's Bluetooth HCI device can be docked to the SDK's HCI operation interface to achieve real Bluetooth behavior.

[0089] The present invention also discloses an electronic device, Figure 3 This is a schematic diagram of the composition of an electronic device according to an embodiment of the present invention; Figure 3 At the hardware level, the electronic device includes a memory, a processor, and at least one network interface. The processor may be a microprocessor, and the memory may include internal memory, such as random access memory (RAM) or non-volatile memory. Of course, the electronic device may also include other hardware as needed.

[0090] The processor, network interface, and memory may be interconnected via an internal bus, such as an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industrial Standard Architecture) bus. The bus may include an address bus, a data bus, a control bus, and the like. The memory is used to store programs (which may include operating system programs and application programs). The programs may include program code, which may include computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0091] In one embodiment, the processor can read the corresponding program from the non-volatile memory into the memory and then run it; the processor can execute the program stored in the memory and is specifically used to perform the following operations (see Figure 2 ):

[0092] The virtual machine module simulates the CPU to execute program instructions;

[0093] The cache simulator simulates cache hits and replacement strategies and calculates miss rates;

[0094] The bus simulator simulates CPU bus access;

[0095] The memory legitimacy analyzer checks the legitimacy of CPU bus accesses, and the legitimacy of memory is dynamically adjusted while the program is running;

[0096] The function dynamic tracking module monitors the set function calls;

[0097] The performance sampling module acquires parameters representing performance;

[0098] The on-chip emulation module and the virtual machine module cooperate to enable a set number of hardware breakpoints on a physical chip;

[0099] The debugging server module receives and responds to control requests from a debugger;

[0100] The script interpretation and execution module communicates with the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip emulation module, and the debugging server, and can send control commands to the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip emulation module, and the debugging server.

[0101] The present application further discloses a storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the following steps of the method of the present application (see Figure 2 ):

[0102] The virtual machine module simulates CPU execution of program instructions;

[0103] The cache simulator simulates cache hits and replacement strategies and counts missing rates;

[0104] The bus simulator simulates CPU bus access;

[0105] The memory legality analyzer checks the legality of CPU bus access, and the legality of memory is dynamically adjusted during program execution;

[0106] The function dynamic tracking module listens to set function calls;

[0107] The performance sampling module acquires parameters representing performance;

[0108] The on-chip emulation module and the virtual machine module cooperate to enable a set number of hardware breakpoints on a physical chip;

[0109] The debugging server module receives and responds to control requests from a debugger;

[0110] The script interpretation and execution module communicates with the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip emulation module, and the debugging server, and can send control commands to the virtual machine module, the memory legality analyzer, the function dynamic tracking module, the performance sampling module, the on-chip emulation module, and the debugging server.

[0111] In summary, the debugging and analysis system, method, electronic device, and storage medium under the scenario of embedded system software development provided by the present application can reduce the workload of embedded system software debugging.

[0112] The present invention can shield the functions of the underlying hardware from embedded software developers, allowing developers to debug their business functions without going through the hardware; through the memory legitimacy analyzer, function dynamic tracking module, script interpretation and execution module and other functions of the debugging and analysis system provided by the present invention, software problems can be quickly located and solved in the product development stage; when finally debugging with the hardware, the workload of most software debugging can be reduced.

[0113] It should be noted that the present application can be implemented in software and / or a combination of software and hardware; for example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of the present application can be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) can be stored in a computer-readable recording medium; for example, a RAM memory, a magnetic or optical drive, or a floppy disk and the like. In addition, some steps or functions of the present application can be implemented in hardware; for example, as a circuit that cooperates with a processor to perform various steps or functions.

[0114] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0115] The description and application of the present invention here are illustrative and are not intended to limit the scope of the present invention to the above-described embodiments. The effects or advantages involved in the embodiments may not be embodied in the embodiments due to interference from various factors, and the description of the effects or advantages is not used to limit the embodiments. Variations and changes to the embodiments disclosed here are possible, and the replacement of the embodiments and various equivalent components are well known to those of ordinary skill in the art. It should be clear to those skilled in the art that the present invention can be implemented in other forms, structures, arrangements, proportions, and with other components, materials, and parts without departing from the spirit or essential characteristics of the present invention. Other variations and changes can be made to the embodiments disclosed here without departing from the scope and spirit of the present invention.

Claims

1. A debugging and analysis system for embedded system software development scenarios, characterized in that: The debugging and analysis system includes: a virtual machine module, a cache simulator, a bus simulator, a memory legality analyzer, a function dynamic tracking module, a performance sampling module, an on-chip simulation module, a debugging server module and a script interpretation and execution module; The script interpretation and execution module is connected to the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server respectively, and can send control commands to the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server; The virtual machine module is respectively connected to the bus simulator, memory legitimacy analyzer, performance sampling module, on-chip simulation module, and debugging server module to simulate the CPU executing program instructions; The cache simulator is connected to the memory legitimacy analyzer, the function dynamic tracking module, and the performance sampling module respectively to simulate cache hits, replacement strategies, and calculate miss rates; The bus simulator is connected to the memory legitimacy analyzer and the function dynamic tracking module respectively to simulate CPU bus access; The memory legitimacy analyzer is used to check the legitimacy of CPU bus access, and the legitimacy of the memory is dynamically adjusted when the program is running; The function dynamic tracking module is used to monitor the set function call; The performance sampling module is used to obtain parameters representing performance; The on-chip simulation module is used to connect to the physical chip and cooperate with the virtual machine module to enable a set number of hardware breakpoints on the physical chip; The debugging server module is connected to the debugger to receive and respond to control requests from the debugger; The performance sampling module is used to collect cache, TLB, and function call events, or sample the program status on the virtual machine module at a fixed frequency, count the number of cache and TLB misses, the proportion of function execution time, the function call stack and call parameters, and analyze the performance of the software; The on-chip simulation module is used to connect to the physical chip under the set debugging scenario, and cooperate with the virtual machine module to enable unlimited hardware breakpoints on the physical chip; setting breakpoints on Flash is similar to software breakpoints, and the code at the breakpoint in Flash will be directly replaced with the breakpoint instruction, and the original instruction will be recorded in the tool; when the physical CPU executes the breakpoint instruction in Flash, a breakpoint exception will be generated, and the tool will capture the exception. At this time, the virtual machine module will take over the context state of the physical processor, execute the original instruction at the breakpoint position, and write the instruction result back to the physical processor; or a real peripheral of the chip can be mounted on the bus simulator to achieve the purpose of the virtual machine module operating the real peripheral.

2. The debugging and analysis system according to claim 1, wherein: The cache simulator includes a cache simulator and / or a TLB simulator; The cache simulator is used to simulate hardware cache hit and replacement strategies and to calculate cache miss rates; The TLB simulator is used to simulate the hardware page table cache hit and replacement strategy, and is used to count the TLB miss rate.

3. The debugging and analysis system according to claim 1, wherein: The virtual machine module includes an input part, an arithmetic unit, a controller, an output part and a general register; RAM, ROM, and virtual interrupt controller are registered on the bus simulator, which is responsible for distributing CPU access to different components; The function dynamic tracking module is used to replace the function entry instruction to interrupt the normal operation of the virtual machine module, so that the outside of the virtual machine module can perceive it, thereby controlling the actual execution logic of the function; the function dynamic tracking module is used for performance analysis and simulation of the underlying device.

4. A debugging and analysis method in an embedded system software development scenario, characterized in that: Based on the debugging and analysis system according to any one of claims 1 to 3, the debugging and analysis method comprises: The virtual machine module simulates the CPU to execute program instructions; The cache simulator simulates cache hits and replacement strategies and calculates miss rates; The bus simulator simulates CPU bus access; The memory legitimacy analyzer checks the legitimacy of CPU bus accesses, and the legitimacy of memory is dynamically adjusted while the program is running; The function dynamic tracking module monitors the set function calls; The performance sampling module obtains parameters that characterize performance; The on-chip simulation module and the virtual machine module work together to enable a set number of hardware breakpoints on the physical chip; The debug server module receives and responds to control requests from the debugger; The script interpretation and execution module communicates with the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server respectively, and can send control commands to the virtual machine module, memory legitimacy analyzer, function dynamic tracing module, performance sampling module, on-chip simulation module and debugging server.

5. The debugging and analysis method according to claim 4, characterized in that: The cache simulator includes a cache simulator and / or a TLB simulator; The cache simulator simulates the hardware cache hit and replacement strategy to calculate the cache miss rate; The TLB simulator simulates the hardware page table cache hit and replacement strategy to calculate the TLB miss rate.

6. The debugging and analysis method according to claim 5, characterized in that: The performance sampling module collects cache, TLB, and function call events, or samples the program status on the virtual machine module at a fixed frequency, counts the number of cache and TLB misses, the proportion of function execution time, the function call stack and call parameters, and analyzes the performance of the software; The on-chip simulation module is connected to the physical chip under the set debugging scenario, and cooperates with the virtual machine module to enable unlimited hardware breakpoints on the physical chip; setting breakpoints on the flash is similar to software breakpoints, and the code at the breakpoint in the flash will be directly replaced with the breakpoint instruction, and the original instruction will be recorded in the tool; when the physical CPU executes the breakpoint instruction in the flash, a breakpoint exception will be generated, and the tool will capture the exception. At this time, the virtual machine module will take over the context state of the physical processor, execute the original instruction at the breakpoint position, and write the instruction result back to the physical processor; or a real peripheral of the chip can be mounted on the bus simulator to achieve the purpose of the virtual machine module operating the real peripheral.

7. The debugging and analysis method according to claim 4, characterized in that: The function dynamic tracking module replaces the function entry instruction to interrupt the normal operation of the virtual machine module, making it perceptible to the outside of the virtual machine module, thereby controlling the actual execution logic of the function; the function dynamic tracking module is used for performance analysis and simulation of the underlying device.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 4 to 7 are implemented.

9. A storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the steps of the method according to any one of claims 4 to 7 are implemented.

Images