Debugging method and apparatus, electronic device, readable storage medium, and program

Abstract

Embodiments of the present application provide a debugging method and apparatus, an electronic device, a computer-readable storage medium, and a computer program. The method comprises: during running of a simulator, storing a snapshot of a running state of the simulator according to a preset rule; when an error occurs during the running of the simulator, storing a historical snapshot matching an error scene of the simulator to a storage module; and acquiring the historical snapshot from the storage module, and loading the historical snapshot into the simulator to debug and repair the simulator. In the embodiments of the present application, when an error occurs during the running of the simulator, the historical snapshot matching the error scene of the simulator can be stored in the storage module for persistent storage; and during subsequent debugging of the simulator, the historical snapshot can be directly acquired from the storage module and loaded into the simulator, so that the simulator can quickly run to the error scene, thereby improving the debugging efficiency of the simulator.

Description

Debugging methods, devices, electronic equipment, readable storage media and programs

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411441412.9, filed on October 15, 2024, entitled "A debugging method, apparatus, electronic device and readable storage medium", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer technology, and in particular to a debugging method, apparatus, electronic device, computer-readable storage medium, and computer program. Background Technology

[0004] In processor design, simulators can be used to simulate processor behavior. Verification of the processor design logic can be achieved by testing the simulator. If the simulator encounters an error, it needs to be debugged based on the error messages, modifying the design logic or behavior of the design under test. After debugging, the verification process continues. In related technologies, the simulator is typically run again from the beginning until it reaches the point where the error occurred, verifying whether the error has been resolved. However, it takes time for the simulator to run the test program to the error point. As the error discovery time increases, the time it takes for the simulator to reach the error point also increases. This leads to a continuous increase in the simulator's debugging overhead, and the entire debugging process involves a large amount of overhead due to repeated runs. Summary of the Invention

[0005] This application provides a debugging method, apparatus, electronic device, computer-readable storage medium, and computer program to solve problems in the related art.

[0006] In a first aspect, embodiments of this application disclose a debugging method applied to a simulator, the simulator being used to simulate processor behavior; the method includes:

[0007] During the operation of the simulator, snapshots of the simulator's running state are saved according to preset rules;

[0008] In the event of an error during simulator operation, a historical snapshot matching the error scenario of the simulator will be saved to the storage module;

[0009] The historical snapshot is retrieved from the storage module and loaded into the simulator for debugging and repair.

[0010] Secondly, embodiments of this application disclose a debugging device applied to a simulator, the simulator being used to simulate processor behavior; the device includes:

[0011] The snapshot module is used to save snapshots of the simulator's running state according to preset rules during the simulator's operation.

[0012] A save module is used to save a historical snapshot that matches the error scene of the simulator to the storage module when the simulator malfunctions.

[0013] A loading module is used to obtain the historical snapshot from the storage module and load the historical snapshot into the simulator for debugging and repairing the simulator.

[0014] Thirdly, embodiments of this application also provide an electronic device, including a processor;

[0015] Memory used to store the processor's executable instructions;

[0016] The processor is configured to execute the instructions to implement the method.

[0017] Fourthly, embodiments of this application also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method described thereon.

[0018] Fifthly, embodiments of this application provide a computer program including computer-readable code, which, when run on a computing processing device, causes the computing processing device to perform the method described thereon.

[0019] This application provides a debugging method that saves snapshots of the simulator's running state according to preset rules during simulator operation. When an error occurs, a historical snapshot matching the simulator's error state is persistently stored in a storage module. Subsequent simulator debugging can directly retrieve this historical snapshot from the storage module and load it into the simulator, allowing it to quickly return to the error state. Compared to rerunning the simulator until it reaches the vicinity of the error state, this application saves simulator state recovery time and reduces debugging overhead. Furthermore, compared to re-executing the test program until the error state occurs, using historical snapshots matching the simulator's error state for state recovery reduces the number of instructions executed by the simulator, mitigating the impact of simulator randomness on state recovery and increasing the success rate of successfully returning to the previous error point, thus improving simulator debugging efficiency.

[0020] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0021] 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.

[0022] Figure 1 is a flowchart of the steps of an embodiment of a debugging method of this application;

[0023] Figure 2 is a schematic diagram of the architecture of a processor according to this application;

[0024] Figure 3 is a structural block diagram of an embodiment of a debugging device of this application;

[0025] Figure 4 is a structural block diagram of an electronic device for debugging provided in this application example. Specific Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe 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, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0028] Referring to Figure 1, a flowchart of a debugging method embodiment of this application is shown. The method may specifically include the following steps:

[0029] Step 101: During the simulator's operation, take snapshots of the simulator's running state according to preset rules;

[0030] Step 102: In the event of an error during simulator operation, save a historical snapshot matching the error scenario of the simulator to the storage module;

[0031] Step 103: Obtain the historical snapshot from the storage module and load the historical snapshot into the simulator to debug and repair the simulator.

[0032] The debugging method provided in this application can be applied to a simulator, which is used to simulate processor behavior. For example, during processor design, a simulator can be used to simulate processor behavior, and the processor design logic can be verified and tested by verifying the simulator. The simulator in this application can be a computer architecture simulator, such as the NEMU simulator or the GEM5 simulator, supporting instruction set architectures such as x86, MIPS32, RISC V64, and RISC V32.

[0033] When using a simulator to verify the Design Under Test (DUT), if the simulator encounters an error, it needs to be debugged based on the error messages. This involves modifying the design logic or behavior of the DUT before continuing the verification process. In related technologies, this typically involves rerunning the simulator from the beginning until it reaches the point where the error occurred, verifying whether the error has been resolved. However, the simulator takes time to reach the error point. As the time required to discover the error increases, the time it takes for the simulator to reach that point also increases. This leads to a continuous increase in the simulator's debugging overhead, and the entire debugging process involves significant overhead from repeated runs. Furthermore, simulators have a degree of randomness; rerunning the simulator to reproduce the error does not guarantee that the simulator will successfully reach the previous error point.

[0034] The debugging method provided in this application can reproduce the emulator's error state using snapshots. Specifically, during the simulator's operation, snapshots of the simulator's running state are saved according to preset rules. For example, snapshot points can be preset according to the test program, and the simulator's running state is saved as a snapshot whenever it reaches a preset snapshot point. Alternatively, a snapshot period can be preset, and the simulator's running state is saved as a snapshot according to the preset snapshot period during the simulator's operation.

[0035] It should be noted that the simulator's runtime state can be snapshotted by copying an image of the simulator's runtime state at a snapshot point. For example, when the simulator reaches a snapshot point, its current runtime state is read and written to a snapshot file as the snapshot data corresponding to that snapshot point. The simulator's runtime state can include the values ​​of its General Purpose Registers (GPRs), Control and Status Registers (CSRs), Program Counter (PC), instruction commit events, and so on. Taking a RISC-V processor simulator as an example, when taking a snapshot of the simulator's runtime state, the corresponding 32 GPR registers, 18 CSR registers, and PC values ​​can be recorded.

[0036] If the simulator encounters an error, a historical snapshot matching the current error state of the simulator can be persistently saved, that is, saved to the storage module. The storage module refers to a module or memory that can provide persistent data storage; for example, the storage module can be a hard disk, disk, read-only memory (ROM), database, cloud database, etc.

[0037] Understandably, when saving snapshots of the simulator's running state, each snapshot can correspond to a historical snapshot. This historical snapshot can be a snapshot file or a set of status values. Each historical snapshot has a tag to identify which snapshot point it corresponds to. For example, each historical snapshot could correspond to a timestamp, or a snapshot point identifier, or each historical snapshot could be numbered according to the order in which they were generated, and the corresponding number could be used as the identifier for the historical snapshot, and so on.

[0038] In the event of an error during simulator operation, the historical snapshot that matches the simulator's error state can be determined based on the tags corresponding to those historical snapshots. For example, if the tag is a timestamp, the historical snapshot with the latest timestamp can be identified as the one matching the simulator's error state; alternatively, if the tag is a snapshot point identifier, the historical snapshot corresponding to the snapshot point identifier closest to the simulator's current error point can be identified as the one matching the simulator's error state; or, if the tag is a number, and the numbers are sorted in ascending order, the historical snapshot with the largest number, i.e., the most recently generated historical snapshot, can be identified as the one matching the simulator's error state.

[0039] When debugging the simulator, previously saved historical snapshots can be retrieved from the storage module and loaded into the simulator, restoring it to its state before the error occurred. This facilitates debugging and repair. For example, a previously saved historical snapshot is retrieved from the storage module, the values ​​of each register recorded in the snapshot are read, and these values ​​are used to overwrite the values ​​of the registers in the simulator, thus restoring the simulator to its state before the error. This allows for quick access to the error scenario during simulator debugging, assisting developers in troubleshooting.

[0040] The debugging method provided in this application saves snapshots of the simulator's running state according to preset rules during simulator operation. When an error occurs, a historical snapshot matching the simulator's error state is persistently stored in a storage module. Subsequent simulator debugging can directly retrieve this historical snapshot from the storage module and load it into the simulator, allowing it to quickly return to the error state. Compared to rerunning the simulator until it reaches the vicinity of the error state, this application saves simulator state recovery time and reduces debugging overhead. Furthermore, compared to re-executing the test program until the error state occurs, using historical snapshots matching the simulator's error state for state recovery reduces the number of instructions executed by the simulator, minimizing the impact of simulator randomness on state recovery and increasing the success rate of successfully returning to the previous error point, thus improving simulator debugging efficiency.

[0041] Optionally, the step of saving snapshots of the simulator's running state according to preset rules during the simulator's operation includes:

[0042] Step S11: When the simulator reaches a preset snapshot point, a backup process is created via a system call; the backup process copies the target variable value from the simulator.

[0043] Step S12: Record the target variable value into a snapshot file to obtain a historical snapshot of the simulator.

[0044] In this embodiment, the simulator's running state can be snapshotted by creating a backup process. Specifically, snapshot points can be pre-set according to the test program. Whenever the simulator reaches a preset snapshot point, a backup process can be created via a system call. This backup process is used to copy the target variable values ​​in the simulator. Then, the copied target variable values ​​are recorded in a snapshot file, thus obtaining a historical snapshot of the simulator. The target variable values ​​can include the values ​​of various registers in the simulator, the address of the currently running instruction, the memory status value, etc. Register values ​​can include the values ​​of the general purpose register (GPR), the control and status register (CSR), etc.; the address of the currently running instruction can be represented by the value of the program counter (PC).

[0045] As an example, when the simulator reaches a preset snapshot point, a backup process can be created using the fork syntax. Referring to Figure 2, a snapshot creation diagram provided by an embodiment of this application is shown. As shown in Figure 2, the parent process in the simulator is used to execute the test program normally. When it reaches the preset snapshot point, a child process, i.e., the backup process, is created through a system call. Exemplarily, the fork() function can be used to create a process almost identical to the original parent process as a backup process via a system call. When a process (parent process) calls the fork() function, the system first allocates resources to the new process (child process or backup process), such as space for storing data and code, and then copies all values ​​from the parent process or the specified target variable value to the new process. After the fork function completes, if the creation of a new process is successful, two processes exist: a child process and a parent process. In the child process, the fork function returns 0; in the parent process, the fork function returns the process ID of the newly created child process. During simulator operation, the return value of fork can be used to determine whether the current process is a child process (backup process) or a parent process.

[0046] After successfully creating the backup process, the parent process continues to execute normally. Upon reaching the next snapshot point, the snapshot is updated. For example, the target variable value in the current parent process is overwritten with the corresponding value in the backup process; or, a new child process is created directly through a system call, i.e., a new backup process is created. When the simulator encounters an error, historical snapshots matching the error scenario are persistently saved.

[0047] This application embodiment generates a lightweight snapshot by creating a backup process through a system call, recording the target variable value, which reduces the complexity of generating snapshots in the simulator and helps improve debugging efficiency.

[0048] Optionally, in the event of an error during simulator operation, a historical snapshot matching the error scenario of the simulator is saved to the storage module, including:

[0049] Step S21: If the simulator malfunctions, switch to the first backup process that is closest to the error location;

[0050] Step S22: Obtain the first snapshot file corresponding to the first backup process; the first snapshot file is used to record the target variable values ​​of the first backup process;

[0051] Step S23: Save the first snapshot file to the storage module.

[0052] In this embodiment, if an error occurs during operation, the system can switch to the first backup process closest to the error location, i.e., the first backup process corresponding to the snapshot point closest to the error location. Then, the first snapshot file corresponding to the first backup process is obtained. For example, the target variable values ​​in the first backup process are recorded in a binary file as the first snapshot file. The first snapshot file is then saved to the storage module, thereby achieving persistent storage of the first snapshot file. This allows the simulator's state to be restored to the state before the current error occurred based on the first snapshot file during subsequent debugging.

[0053] Optionally, the method further includes:

[0054] Step S31: Synchronously run the simulator and the corresponding reference model; the reference model is used to implement the same functions as the simulator;

[0055] Step S32: Obtain the first running state value of the simulator and the second running state value of the reference model;

[0056] Step S33: Compare the first running status value with the second running status value;

[0057] Step S34: If the first running status value and the second running status value do not match, it is determined that the simulator is running incorrectly.

[0058] In this embodiment, a reference model can be used to analyze whether the simulator is malfunctioning. The reference model implements the same functionality as the simulator. For example, a software program simulating the simulator's running state can be written in a high-level language and used as the simulator's reference model. For instance, if the simulator is the NEMU simulator, the reference model could be the SPIKE simulator.

[0059] The simulator and reference model are run synchronously. If the simulator's first running state value does not match the reference model's second running state value, it can be determined that the simulator is malfunctioning. The contents of the first and second running state values ​​can be determined based on the data to be verified in the simulator. For example, the first and second running state values ​​may include values ​​of general-purpose registers, control and status registers, program counter values, instruction commit events, etc. In practical applications, the specific contents of the first and second running state values ​​can be specified according to the actual situation and specific verification requirements.

[0060] The first running state value of the simulator is compared with the second running state value of the reference model. If the first running state value matches the second running state value, for example, the first running state value is the same as the second running state value, or the value of the first running state value falls within the range of the value of the second running state value, etc., it can be considered that the simulator is running without error. At this time, no processing can be done on the simulator and the reference model, and both can continue to run the test program.

[0061] If the first running status value does not match the second running status value—for example, if the first running status value is not the same as the second running status value, or if the value of the first running status value does not fall within the range of the second running status value, etc.—then the emulator can be considered to be malfunctioning. In this case, a snapshot of the emulator's running status can be saved.

[0062] It is understandable that the values ​​of certain intermediate signals are correct within a certain range, making it impossible to directly compare the signal values ​​in the simulator with those in the reference model. In this embodiment, breakpoint logic can be added to these signals. For example, if the current value of the target signal is any value within the target range, no processing is performed, and the simulator and reference model continue running. If the current value of the target signal is not any value within the target range, meaning the current value of the target signal does not conform to the breakpoint logic, then it can be determined that the simulator is malfunctioning, and a snapshot of the simulator's running state is saved.

[0063] Optionally, obtaining the historical snapshot from the storage module and loading the historical snapshot into the simulator includes:

[0064] Step S41: Obtain the historical snapshot from the storage module;

[0065] Step S42: Modify the first running state value of the simulator to the historical state value recorded in the historical snapshot;

[0066] Step S43: Modify the second running state value of the reference model to the historical state value recorded in the historical snapshot.

[0067] When restoring the simulator's running state, the model's running state can be restored synchronously based on historical snapshots. Specifically, previously saved historical snapshots can be retrieved from the storage module, the simulator's first running state value can be modified to the historical state value recorded in that snapshot, and the reference model's second running state value can be modified to the historical state value recorded in that snapshot. This ensures that the simulator and the reference model are synchronized, allowing for verification of the debugging results based on the reference model during the debugging process.

[0068] Optionally, the step of saving snapshots of the simulator's running state according to preset rules during the simulator's operation includes:

[0069] Step S51: Set a counter; the counter is used to count the number of instructions executed by the simulator, and the initial value of the counter is a preset value;

[0070] Step S52: After the simulator executes each instruction, increment the counter value by n, where n > 0;

[0071] Step S53: If the counter value is greater than or equal to the first preset value, a snapshot of the simulator's running state is saved, and the counter value is restored to the initial value.

[0072] Step S54: Continue running the simulator and update the counter according to the execution status of the simulator's instructions until the termination condition is met, at which point stop the operation of the simulator and the counter.

[0073] In this embodiment, the snapshot timing can be determined based on the number of instructions executed by the simulator. For example, a counter can be set to count the number of instructions executed by the simulator. After each instruction is executed, the counter value is incremented by n, where n > 0. If the counter value is greater than or equal to a first preset value, a snapshot of the simulator's running state can be saved, and the counter value can be restored to its initial value. Then, the simulator continues to run, and the counter is updated until a termination condition is met, at which point the simulator and the counter stop running. The termination condition may include: the simulator encountering an error, or the simulator completing the test program.

[0074] For example, assuming the initial value of the counter is 0 and n=1, meaning the counter is incremented by 1 for each instruction executed by the simulator. When the counter value is greater than or equal to a first preset value, such as 1000, a snapshot is triggered to save the simulator's running state. Then, the counter value is restored to its initial value, and the simulator continues to run, incrementing the counter by 1 after each instruction executed. This process continues until a snapshot is triggered every 1000 instructions executed by the simulator. If the next snapshot is not triggered and an error is detected in the simulator, the latest generated snapshot is identified as the historical snapshot matching the simulator's error state, and this historical snapshot is saved to the storage module.

[0075] In summary, this application provides a debugging method that saves snapshots of the simulator's running state according to preset rules during simulator operation. When an error occurs, a historical snapshot matching the simulator's error state is stored persistently in a storage module. Subsequent simulator debugging can directly retrieve the historical snapshot from the storage module and load it into the simulator, allowing the simulator to quickly return to the error state, saving simulator state recovery time and reducing debugging overhead. Furthermore, compared to re-executing the test program until the error state occurs, using historical snapshots matching the simulator's error state for state recovery reduces the number of instructions executed by the simulator, minimizing the impact of simulator randomness on state recovery, and increasing the success rate of successfully returning to the previous error point, thus improving simulator debugging efficiency.

[0076] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of this application.

[0077] Device Examples

[0078] Referring to Figure 3, a structural block diagram of a debugging device according to this application is shown, which is applied to a simulator used to simulate processor behavior; the device may specifically include:

[0079] The snapshot module 301 is used to save snapshots of the simulator's running state according to preset rules during the simulator's operation.

[0080] The saving module 302 is used to save a historical snapshot that matches the error scene of the simulator to the storage module when the simulator malfunctions.

[0081] The loading module 303 is used to obtain the historical snapshot from the storage module and load the historical snapshot into the simulator for debugging and repairing the simulator.

[0082] Optionally, the snapshot module includes:

[0083] A submodule is created to create a backup process via a system call when the simulator reaches a preset snapshot point; the backup process copies the target variable value from the simulator.

[0084] The recording submodule is used to record the target variable value to a snapshot file to obtain a historical snapshot of the simulator.

[0085] Optionally, the storage module includes:

[0086] The switching submodule is used to switch the first backup process closest to the error site in the event of an error during simulator operation.

[0087] The acquisition submodule is used to acquire the first snapshot file corresponding to the first backup process; the first snapshot file is used to record the target variable value of the first backup process.

[0088] The save submodule is used to save the first snapshot file to the storage module.

[0089] Optionally, the device further includes:

[0090] The control module is used to synchronously run the simulator and the reference model corresponding to the simulator; the reference model is used to implement the same functions as the simulator.

[0091] A status acquisition module is used to acquire the first running status value of the simulator and the second running status value of the reference model;

[0092] The comparison module is used to compare the first running status value with the second running status value;

[0093] The determination module is used to determine that the simulator is malfunctioning when the first running status value does not match the second running status value.

[0094] Optionally, the loading module includes:

[0095] A snapshot acquisition submodule is used to acquire the historical snapshot from the storage module;

[0096] The first modification submodule is used to modify the first running state value of the simulator to the historical state value recorded in the historical snapshot;

[0097] The second modification submodule is used to modify the second running state value of the reference model to the historical state value recorded in the historical snapshot.

[0098] Optionally, the snapshot module includes:

[0099] The settings submodule is used to set a counter; the counter is used to count the number of instructions executed by the simulator, and the initial value of the counter is a preset value;

[0100] The counting submodule is used to increment the counter value by n, where n > 0, after the simulator executes each instruction.

[0101] The snapshot submodule is used to save a snapshot of the simulator's running state and restore the counter's count value to the initial value if the counter's count value is greater than or equal to a first preset value.

[0102] An update submodule is used to continue running the simulator and update the counter according to the simulator's instruction execution status until the termination condition is met, at which point the simulator and the counter stop running.

[0103] Optionally, the simulator is a computer architecture simulator.

[0104] Optionally, the simulator may include either the NEMU simulator or the GEM5 simulator.

[0105] Optionally, the simulator's running state includes one or more of the following: the value of a general-purpose register in the simulator, the value of a control and status register, the value of a program counter, and an instruction commit event.

[0106] Optionally, the target variable value may include one or more of the following: the value of each register in the simulator, the address of the currently running instruction, and the memory status value.

[0107] Optionally, the backup process is created by the fork function.

[0108] Optionally, the acquisition submodule includes:

[0109] The acquisition unit is used to record the target variable values ​​in the first backup process into a binary file as the first snapshot file.

[0110] Optionally, the device further includes:

[0111] A normal operation detection module is used to determine that the simulator is running normally if the first running status value matches the second running status value.

[0112] In summary, the debugging apparatus provided in this application saves snapshots of the simulator's running state according to preset rules during simulator operation. When an error occurs, a historical snapshot matching the simulator's error state is stored persistently in a storage module. Subsequent simulator debugging can directly retrieve the historical snapshot from the storage module and load it into the simulator, allowing the simulator to quickly reach the error state. Compared to rerunning the simulator until it reaches the vicinity of the error state, this application saves simulator state recovery time and reduces simulator debugging overhead. Furthermore, compared to re-executing the test program until the error state occurs, using historical snapshots matching the simulator's error state for state recovery reduces the number of instructions executed by the simulator, minimizing the impact of simulator randomness on state recovery and increasing the success rate of the simulator successfully reaching the previous error point, thus improving simulator debugging efficiency.

[0113] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0114] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0115] Regarding the processor in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0116] Referring to Figure 4, which is a structural block diagram of an electronic device for verification provided in an embodiment of this application, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory stores executable instructions, which cause the processor to execute the debugging method of the aforementioned embodiment.

[0117] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0118] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one line is used in Figure 4, but this does not indicate that there is only one bus or one type of bus.

[0119] The memory may be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it may be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0120] This application also provides a non-transitory computer-readable storage medium, which, when the instructions in the storage medium are executed by the processor of an electronic device (server or terminal), enables the processor to execute the debugging method shown in FIG1.

[0121] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0122] The terms "an embodiment," "embodiment," or "one or more embodiments" as used herein mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this application. Furthermore, please note that the examples of the phrase "in one embodiment" do not necessarily all refer to the same embodiment.

[0123] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0124] In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0125] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0126] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0127] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0128] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0129] The above provides a detailed description of the debugging method, apparatus, electronic device, computer-readable storage medium, and computer program provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A debugging method, wherein, Applied to a simulator, which is used to simulate processor behavior; The method includes: During the operation of the simulator, snapshots of the simulator's running state are saved according to preset rules; In the event of an error during simulator operation, a historical snapshot matching the error scenario of the simulator will be saved to the storage module; The historical snapshot is retrieved from the storage module and loaded into the simulator for debugging and repair.

2. The method of claim 1, wherein, The step of taking snapshots of the simulator's running state according to preset rules during the simulator's operation includes: When the simulator reaches a preset snapshot point, a backup process is created via a system call; the backup process copies the target variable value from the simulator. The target variable value is recorded in a snapshot file to obtain a historical snapshot of the simulator.

3. The method of claim 2, wherein, In the event of an error during simulator operation, a historical snapshot matching the error scenario of the simulator is saved to the storage module, including: If the simulator encounters an error, switch to the first backup process that is closest to the error location. Obtain the first snapshot file corresponding to the first backup process; the first snapshot file is used to record the target variable values ​​of the first backup process; Save the first snapshot file to the storage module.

4. The method of claim 1, wherein, The method further includes: The simulator and its corresponding reference model are run synchronously; the reference model is used to implement the same functions as the simulator. Obtain the first running state value of the simulator and the second running state value of the reference model; Compare the first operating status value with the second operating status value; If the first running status value does not match the second running status value, it is determined that the simulator is malfunctioning.

5. The method of claim 4, wherein, The step of obtaining the historical snapshot from the storage module and loading the historical snapshot into the simulator includes: The historical snapshot is obtained from the storage module; Modify the first running state value of the simulator to the historical state value recorded in the historical snapshot; The second running state value of the reference model is modified to the historical state value recorded in the historical snapshot.

6. The method of claim 1, wherein, The step of taking snapshots of the simulator's running state according to preset rules during the simulator's operation includes: Set a counter; the counter is used to count the number of instructions executed by the simulator, and the initial value of the counter is a preset value; After the simulator executes each instruction, the counter value is incremented by n, where n > 0; If the counter value is greater than or equal to the first preset value, a snapshot of the simulator's running state is saved, and the counter value is restored to the initial value. Continue running the simulator and update the counter according to the execution status of the simulator's instructions until the termination condition is met, at which point stop running the simulator and the counter.

7. The method of claim 1, wherein, The simulator is a computer architecture simulator.

8. The method of claim 7, wherein, The simulator includes either the NEMU simulator or the GEM5 simulator.

9. The method of claim 1, wherein, The simulator's running state includes one or more of the following: the values ​​of general-purpose registers, control and status registers, program counter, and instruction commit events.

10. The method of claim 2, wherein, The target variable value includes one or more of the following: the value of each register in the simulator, the address of the currently running instruction, and the memory status value.

11. The method of claim 2, wherein, The backup process is created by the fork function.

12. The method of claim 3, wherein, The step of obtaining the first snapshot file corresponding to the first backup process includes: The target variable values ​​in the first backup process are recorded into a binary file, which serves as the first snapshot file.

13. The method of claim 4, wherein, The method further includes: If the first running status value matches the second running status value, the simulator is determined to be running normally.

14. A debugging apparatus, wherein, Applied to a simulator, which is used to simulate processor behavior; The device includes: The snapshot module is used to save snapshots of the simulator's running state according to preset rules during the simulator's operation. A save module is used to save a historical snapshot that matches the error scene of the simulator to the storage module when the simulator malfunctions. A loading module is used to obtain the historical snapshot from the storage module and load the historical snapshot into the simulator for debugging and repairing the simulator.

15. The apparatus of claim 14, wherein, The snapshot module includes: A submodule is created to create a backup process via a system call when the simulator reaches a preset snapshot point; the backup process copies the target variable value from the simulator. The recording submodule is used to record the target variable value to a snapshot file to obtain a historical snapshot of the simulator.

16. An electronic device, comprising: The electronic device includes a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store executable instructions that cause the processor to perform the debugging method as described in any one of claims 1 to 13.

17. A readable storage medium, wherein, When the instructions in the readable storage medium are executed by the processor of the electronic device, the processor is enabled to perform the debugging method as described in any one of claims 1 to 13.

18. A computer program comprising computer-readable code that, when executed on a computing processing device, causes the computing processing device to perform the method according to any one of claims 1 to 13.

Images