Debugging method and device of operating system, equipment, storage medium and program product

Abstract

The invention discloses a debugging method and device of an operating system, equipment, a storage medium and a program product, and relates to the technical field of system debugging. The operating system comprises a system memory area, the system memory area comprises a core memory area and an isolation memory area, the isolation memory area comprises a crash command line segment, and the crash command line segment is used for storing codes and data of a debugging command line when the operating system crashes. Modifying a memory management unit (MMU) page table, modifying the permission of codes in the crash command line segment to be readable and executable, modifying the permission of data in the crash command line segment to be readable and writable, and modifying the permission of an operating system in the MMU page table to be read-only so as to enter a crash command line mode; receiving a debugging command input by a user, and debugging the crashed operating system; according to the method, interactive diagnosis can be performed in real time without damaging a collapse site.

Description

Technical Field

[0001] This application belongs to the technical field of system debugging, and particularly relates to a debugging method, apparatus, device, storage medium and program product for an operating system. Background Technology

[0002] Embedded operating systems may encounter serious errors during operation due to unpredictable kernel defects, hardware failures, or other reasons, causing the system to cease operation. This state is commonly referred to as a crash. After a system crash, current techniques typically employ simple infinite loops, directly displaying the error context using the operating system's internal interfaces, or generating a coredump file for debugging.

[0003] However, most existing debugging solutions have the problems of easily destroying the crash scene and being unable to perform real-time interactive diagnosis. Summary of the Invention

[0004] This application provides a debugging method, apparatus, device, storage medium, and program product for an operating system, which can perform interactive diagnosis in real time without destroying the crash scene.

[0005] In a first aspect, embodiments of this application provide a debugging method for an operating system. The operating system includes a system memory area, which includes a kernel memory area and an isolated memory area. The isolated memory area includes a crash command line segment, which stores the code and data of debugging command lines for operating system crashes. The debugging method includes: Upon detecting an operating system crash, the Memory Management Unit (MMU) page table is modified to change the permissions of the code in the crash command line segment to read and execute, the permissions of the data in the crash command line segment to read and write, and the permissions of the operating system in the MMU page table to read only, in order to enter crash command line mode. It receives debugging commands from the user and debugs the crashed operating system.

[0006] In some embodiments, the debugging command includes access symbols; receiving user-inputted debugging commands and debugging a crashed operating system includes: It receives debugging commands input by the user and determines the target address corresponding to the access symbol through the symbol table in the code of the crash command line segment; the symbol table includes global access symbols that are allowed to be accessed by the crash command line, as well as the address of the data in the operating system kernel memory area corresponding to the access symbol; Read the target data from the target address in the operating system kernel memory area; Debugging of a crashed operating system based on target data.

[0007] In some embodiments, before determining the target address corresponding to the access symbol through the symbol table, the debugging method further includes: Once the operating system compilation chain is complete, extract the global access symbols that are allowed by the crash command line, as well as the addresses of the data in the operating system kernel memory area corresponding to the global access symbols. Generate a symbol table, which includes global access symbols and the correspondence between the addresses of the global access symbols; Compile and link the symbol table into the code of the crash command line.

[0008] In some embodiments, before modifying the Memory Management Unit (MMU) page table upon detecting an operating system crash, the debugging method further includes: During the normal startup process of the operating system, the initial MMU page table is configured. The permissions of the code and data in the crash command line segment in the initial MMU page table are configured to be unreadable, unwritable, and unexecutable.

[0009] In some embodiments, the debugging method further includes: Receive a dump command, which includes the memory address of the dump data and the identifier of the storage device for the dump data; In response to a dump command, the dump data corresponding to the memory address is stored in the device corresponding to the storage device identifier.

[0010] In some embodiments, the debugging method further includes: If an error is detected during the execution of a crash command, or if a user's target operation command is received, a central processing unit (CPU) exception message is generated.

[0011] In some embodiments, the debugging method further includes: Receive reset command; In response to a reset command, the command line context is reset to restore the executable command to the state of the crashed command.

[0012] Secondly, embodiments of this application provide an operating system debugging apparatus, the apparatus comprising: The permissions module is used to modify the Memory Management Unit (MMU) page table when an operating system crash is detected. It changes the permissions of the code in the crash command line segment to read and execute, changes the permissions of the data in the crash command line segment to read and write, and changes the permissions of the operating system in the MMU page table to read only, so as to enter the crash command line mode. The interactive module receives debugging commands from the user and debugs the crashed operating system.

[0013] Thirdly, embodiments of this application provide a terminal device, the device including: a processor and a memory storing computer program instructions; The processor implements debugging methods for operating systems, as described in the first aspect, when executing computer program instructions.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the debugging method of the operating system as described in the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to execute a debugging method for an operating system as described in the first aspect.

[0016] The operating system debugging method of this application, when an operating system crash is detected, modifies the MMU page table to set the code permissions of the crash command line segment to readable and executable, the data permissions to readable and writable, and the operating system permissions to read-only. This allows the code and data of the crash command line segment to be called and operated normally to enter the crash command line mode, while setting the operating system permissions to read-only prevents tampering with the original data and state of the system, thus effectively protecting the crash scene from destruction. The step of receiving debugging commands input by the user and debugging the crashed operating system enables real-time interaction between the user and the debugging environment, supports the user to input debugging commands as needed to carry out diagnosis, and realizes real-time interactive diagnosis. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the debugging method for the operating system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the interactive debugging process provided in the embodiments of this application; Figure 3 This is a schematic diagram of the symbol table compilation process provided in the embodiments of this application; Figure 4 This is a schematic diagram of the dumping process provided in the embodiments of this application; Figure 5 This is a schematic diagram of the reset process provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the operating system debugging device provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0019] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0020] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0021] Embedded operating systems may encounter serious errors during operation due to unpredictable kernel defects, hardware failures, or other reasons, causing the system to cease operation; this state is commonly referred to as a crash. After a system crash, quickly locating and diagnosing the root cause of the problem without destroying the error context remains a long-standing technical challenge.

[0022] Several existing methods for handling operating system crashes have the following drawbacks: Using a simple infinite loop lacks real-time interactive diagnostics, requires a physical debugger, and hardware debugging interfaces may be limited or unavailable. Error context information cannot be actively obtained, requiring manual backtracking. Using internal operating system interfaces to display the error context relies on the operating system's own functions; if these modules are damaged, secondary errors may be triggered, potentially overwriting critical context data and failing to isolate sensitive data. Generating coredump files requires offline file analysis, lacks real-time interactive debugging, cannot dynamically verify repair hypotheses, and is time-consuming for generating dumps on large memory devices, potentially resulting in the loss of transient states.

[0023] Therefore, most existing debugging solutions have the problems of easily destroying the crash scene and being unable to perform real-time interactive diagnosis.

[0024] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, computer storage medium, and computer program product for debugging an operating system. This method, upon detecting an operating system crash, modifies the MMU page table, setting the code permissions in the crash command line segment to readable and executable, the data permissions to readable and writable, and the operating system permissions to read-only. This allows the code and data in the crash command line segment to be normally invoked and manipulated to enter the crash command line mode, while setting the operating system permissions to read-only prevents tampering with the original system data and state, effectively protecting the crash scene from destruction. Furthermore, by receiving user-inputted debugging commands and debugging the crashed operating system, real-time interaction between the user and the debugging environment is achieved, supporting users to input debugging commands as needed for diagnosis, thus realizing real-time interactive diagnosis.

[0025] The debugging method of the operating system provided in the embodiments of this application will be introduced first.

[0026] Figure 1 This illustration shows a flowchart of an operating system debugging method according to an embodiment of this application. The operating system includes a system memory area, which further includes a kernel memory area and an isolated memory area. The isolated memory area includes a crash command line segment, which stores the code and data of debugging command lines for operating system crashes, such as... Figure 1 As shown, the debugging methods may include: S101 to S102.

[0027] S101, upon detecting an operating system crash, modify the Memory Management Unit (MMU) page table, change the permissions of the code in the crash command line segment to read and execute, change the permissions of the data in the crash command line segment to read and write, and change the permissions of the operating system in the MMU page table to read only, in order to enter the crash command line mode.

[0028] In some embodiments, after detecting an operating system crash, the page table entry corresponding to the crash command line segment code region in the MMU page table is located, and the permission flag in the page table entry is modified to set the permission bit of the code page to allow read and execute operations, so that the code of the crash command line segment has readable and executable permissions.

[0029] Locate the page table entry in the crash command line segment data area and adjust its permission flag to allow reading and writing, ensuring that the data can be read and written normally.

[0030] Then, iterate through all page table entries in the operating system kernel area of ​​the MMU page table, modify the permission bits of the corresponding data segments to read-only, and retain the read and execute permissions for the code segments and read-only data. After completing the overall reconstruction of page table permissions, trigger the mode switching process and enter the crash command line mode.

[0031] In some embodiments, entering crash command line mode may include: The program counter is set to point to the entry address of the crash command segment, a separate stack pointer is configured within the crash command segment area, and a jump instruction is executed. The jump instruction transfers the CPU's execution control from the operating system to the crash command segment, thus entering crash command mode.

[0032] This application embodiment modifies the MMU page table to set the code permissions of the crash command line segment to readable and executable, and the data permissions to readable and writable. This ensures that the code in the crash command line segment can run normally and the data can be read and written, thus entering the crash command line mode and providing an interactive basis for subsequent debugging. At the same time, the operating system permissions are set to read-only, reducing the possibility of the operating system core data being tampered with, effectively protecting the crash scene from destruction, and maintaining the original state at the time of the crash.

[0033] S102 receives user-inputted debugging commands to debug the crashed operating system.

[0034] In some embodiments, a crash command line interactive interface is built in crash command line mode; wherein, the crash command line interactive interface has built-in basic debugging commands, and when the user enters debugging commands through the crash command line interactive interface, the crash command line interactive interface provides a command line prompt, which corresponds to the basic debugging commands.

[0035] In some embodiments, receiving debug commands input by the user may include: Receive debugging commands sent by the user through the crash command line interactive interface. The user can select the basic debugging command to enter through the prompt of the crash command line interactive interface.

[0036] This application embodiment achieves real-time interaction between the user and the debugging environment by receiving debugging commands input by the user and debugging the crashed operating system. The user can input instructions according to diagnostic needs and directly perform targeted debugging operations on the crashed system, realizing the effect of real-time interactive diagnosis and improving the flexibility and targeting of debugging.

[0037] This application embodiment modifies the MMU page table when an operating system crash is detected, setting the code permissions in the crash command line segment to readable and executable, the data permissions to readable and writable, and the operating system permissions to read-only. This allows the code and data in the crash command line segment to be normally called and manipulated to enter the crash command line mode, while setting the operating system permissions to read-only prevents tampering with the original system data and state, thus effectively protecting the crash scene from destruction. The step of receiving user-inputted debugging commands and debugging the crashed operating system enables real-time interaction between the user and the debugging environment, supporting users to input debugging commands as needed for diagnosis, and realizing real-time interactive diagnosis.

[0038] In some embodiments, such as Figure 2 As shown, the debugging commands include access symbols; receiving user-inputted debugging commands to debug the crashed operating system can include: S201 to S203.

[0039] S201 receives the debugging command input by the user and determines the target address corresponding to the access symbol through the symbol table in the code of the crash command line segment; wherein, the symbol table includes global access symbols that are allowed to be accessed by the crash command line, and the address of the data in the operating system kernel memory area corresponding to the access symbol.

[0040] In some embodiments, a debugging command input by the user is received, the debugging command is parsed to extract the access symbol, the symbol table is traversed to match the access symbol, the entry associated with the access symbol in the symbol table is found, and the target address of the operating system kernel memory area corresponding to the access symbol is determined based on the entry.

[0041] In some embodiments, the linker of the crash command segment does not link to access symbols and the addresses of the data corresponding to access symbols that are not included in the symbol table, and cannot directly access them in the crash command segment, thus isolating the access symbols and the addresses of the data corresponding to the access symbols in the operating system kernel memory area.

[0042] In some embodiments, debugging commands may include core data viewing commands, memory region reading commands, function call commands, fault scene export commands, and system status traversal commands.

[0043] This application embodiment receives user debugging commands and uses the symbol table in the crash command line segment code to determine the target address corresponding to the access symbol, ensuring that only global symbols and data addresses in the symbol table can be accessed, avoiding illegal access to sensitive or unauthorized areas, providing a clear address pointer for subsequent reading of target data, and realizing the controllability and accuracy of debugging access.

[0044] S202, read the target data from the target address in the operating system kernel memory area.

[0045] In some embodiments, reading target data from a target address in the operating system kernel memory area may include: Calling functions in the operating system's kernel memory area; Access data in the operating system kernel memory area.

[0046] In some embodiments, calling functions in the operating system kernel memory area may include: Obtain the target address through the symbol table; Convert the target address to a function pointer; Call functions in the operating system kernel memory area based on function pointers.

[0047] In some embodiments, data accessed in the operating system kernel memory area may include: Obtain the target address through the symbol table; Use the target address as a pointer; Data in the operating system kernel memory area can be accessed in read-only mode using pointers.

[0048] This application embodiment, by reading target data from the target address in the operating system kernel memory area, can obtain key data of the crash scene without modifying the contents of the operating system kernel memory area. This preserves the original state of the crash scene and provides real and effective data support for debugging and analysis.

[0049] S203, Debugging a crashed operating system based on target data.

[0050] In some embodiments, debugging a crashed operating system based on target data may include: Compare the target data with the system's normal operating baseline data to identify outliers in the target data; Locate fault clues based on anomalies.

[0051] This application embodiment debugs the crashed operating system based on the read target data, enabling debuggers to conduct fault analysis based on this raw data, achieve accurate diagnosis of the cause of the crash, and achieve the purpose of real-time interactive debugging. At the same time, since the crash site is not destroyed, the reliability of the debugging results is guaranteed.

[0052] This application's embodiments utilize the built-in symbol table in the crash command line segment to achieve precise mapping between accessed symbols and target addresses in debugging commands. This clearly defines the range of allowed access to operating system kernel memory data, simplifying user debugging operations and eliminating the need to manually input complex physical addresses. Access control through the symbol table restricts debugging permission boundaries, preventing unauthorized access to sensitive system core data. Simultaneously, reading target address data supports debugging analysis, improving the accuracy and efficiency of crash scene data acquisition, which is beneficial for locating the root cause of the fault.

[0053] In some embodiments, such as Figure 3 As shown, before determining the target address corresponding to the access symbol through the symbol table, the debugging method may also include: S301 to S303.

[0054] S301, once the operating system compilation chain is complete, extracts the global access symbols that are allowed to be accessed by the crash command line, as well as the addresses of the data in the operating system kernel memory area corresponding to the global access symbols.

[0055] After the operating system compilation chain is completed, all global symbols are extracted from the compiled output symbol file. Based on debugging requirements, symbols that are allowed to be accessed by the crash command line are selected: symbols that are not allowed to be accessed are removed. The data addresses of the operating system kernel memory area corresponding to the selected symbols are parsed by the compilation chain tool to establish a mapping relationship between symbols and addresses.

[0056] In some embodiments, the compiler chaining tool may include a symbol list tool (name mangling, nm), an object copy tool (object copy, objcopy), or a custom script.

[0057] In some embodiments, global access symbols that are allowed to be accessed by the crash command line may include variables in the operating system kernel used to characterize the system's running state, pointers to the head nodes of kernel linked lists, instances of kernel parameter structures, symbols of harmless functions that are allowed to be called, and symbols of hardware register mapping addresses.

[0058] Among them, variables used to characterize the system's operating state may include system mode identifiers and task status markers.

[0059] The kernel linked list head node pointer can include the ready queue head pointer.

[0060] Kernel parameter structure instances can include CPU state structures.

[0061] Permissible callable harmless function symbols may include log output functions.

[0062] Hardware register mapping address symbols can include interrupt controller register symbols.

[0063] In some embodiments, symbols that are not allowed to be accessed may include function symbols involving sensitive system operations, unexported private variable symbols, write operation-related symbols that may corrupt the crash scene, and sensitive symbols of core control structures in the operating system kernel memory area used for process scheduling and memory management.

[0064] Among them, function symbols for system-sensitive operations can include memory modification functions and permission change functions.

[0065] Sensitive symbols used in core control structures for process scheduling and memory management may include: page table modification functions and task switching function symbols.

[0066] This application embodiment filters and extracts allowed global symbols and their corresponding core memory addresses, clarifies the access scope of crash command lines, retains only safe and diagnostically valuable symbols, excludes symbols related to sensitive operations, provides a compliant data foundation for symbol table construction, and ensures the security and targeting of debugging access.

[0067] S302, Generate a symbol table, which includes global access symbols and the correspondence between the addresses of the global access symbols.

[0068] In some embodiments, generating a symbol table may include: Obtain the global access symbols that are allowed by the crash command line, and the address of the data in the operating system kernel memory area corresponding to the global access symbols; Construct an initial symbol mapping dataset based on the global access symbols and the addresses of the data corresponding to the global access symbols; The initial symbol mapping dataset is processed according to a preset format to generate structured symbol data; Based on the structured symbol data, a script tool is used to convert it into a binary symbol table file containing metadata and a fixed storage structure; The verified symbol table is obtained by performing data verification based on the binary symbol table file; Based on the verified symbol table, a final symbol table containing the mapping between global access symbols and their corresponding addresses is generated.

[0069] This application embodiment establishes a link between debugging commands and the kernel memory area by generating a symbol table that maps symbols to addresses. This allows crash command lines to accurately locate target addresses through symbols. At the same time, the symbol table only contains allowed access content, ensuring the controllability and accuracy of subsequent debugging access.

[0070] S303 compiles and links the symbol table into the code of the crash command line.

[0071] In some embodiments, compiling and linking the symbol table into the crash command line code may include: Obtain the symbol table file; Generate symbol table source files for the adaptation compilation chain based on the symbol table file; The symbol table source file and the crash command line code file are preprocessed to obtain the preprocessed code file. The preprocessed code file is compiled by the compiler to generate an object file containing symbol table data. The symbol table is compiled and linked into the crash command line code by linking the object file containing the symbol table data with other code object files of the crash command line.

[0072] This application embodiment compiles and links the symbol table into the crash command line code, making the symbol table built-in data of the crash command line segment. It can be directly called in the debugging environment without relying on external resources, ensuring efficient and independent symbol lookup during debugging. At the same time, the compilation and linking mechanism ensures the compatibility and operational stability of the symbol table and the crash command line code.

[0073] This application embodiment extracts legal global access symbols and their corresponding kernel memory addresses during the operating system compilation stage, generates a symbol table, and links it to the crash command line code. This pre-sets the symbol mapping relationships required for debugging, avoiding the resource consumption and security risks of dynamically generating a symbol table after a crash. At the same time, by solidifying the symbol table during compilation, the accuracy and stability of symbol mapping are ensured, providing a reliable foundation for symbol-based address resolution and data access, and guaranteeing the smoothness and security of the debugging process.

[0074] In some embodiments, before modifying the Memory Management Unit (MMU) page table upon detecting an operating system crash, the debugging method may further include: During the normal startup process of the operating system, the initial MMU page table is configured. The permissions of the code and data in the crash command line segment in the initial MMU page table are configured to be unreadable, unwritable, and unexecutable.

[0075] In some embodiments, during the normal startup process of the operating system, the initial MMU page table is configured. The permissions for both code and data in the crash command line segment of the initial MMU page table are configured to be unreadable, unwritable, and unexecutable. This may include: Obtain the memory layout plan and memory address range of the crash command line segment during operating system startup; The page table entry partitioning rules for the initial MMU page table are determined based on the memory layout plan; Locate the corresponding page table entry based on the memory address range of the crash command segment; Based on the page table entry location, set the permission bits of the page table entry corresponding to the crash command line segment code region to be unreadable, unwritable, and unexecutable; based on the page table entry location, set the permission bits of the page table entry corresponding to the crash command line segment data region to be unreadable, unwritable, and unexecutable. Complete the configuration of crash command line segment permissions in the initial MMU page table and load and apply them.

[0076] This application embodiment configures the initial MMU page table during the normal operating system startup phase and sets the code and data permissions of the crash command line segment to be unreadable, unwritable, and unexecutable. This strictly restricts access to the crash command line segment during normal system operation, preventing it from being misoperated, maliciously tampered with, or accidentally executed, and avoiding interference with the normal operation of the system. At the same time, the crash command line segment is placed in an isolated protection state to ensure that it maintains its original integrity during normal system operation, laying a safe foundation for using this segment for debugging and diagnosis when the system crashes. This effectively isolates debugging functions from the normal system operation process, improving the stability and security of system operation.

[0077] In some embodiments, such as Figure 4As shown, the debugging methods may also include: S401 to S402.

[0078] S401, Receive dump command, the dump command includes the memory address of the dump data and the storage device identifier of the dump data.

[0079] In some embodiments, receiving a dump command may include: Obtain command data input by the user through the crash command line interactive interface; Parse the command content containing key fields from the instruction data; Identify the dump instruction identifier based on the command content; Extract the accompanying memory address parameters and storage device identifier parameters based on the dump instruction identifier.

[0080] The memory address parameter can include the starting address of the dump data or the length of the dump data.

[0081] Storage device identification parameters may include device name and mount path.

[0082] In one example, the memory address parameter is dump_memory. <start> <end>to <device>.

[0083] This application embodiment, by receiving a dump command containing the memory address of the dump data and the storage device identifier, clarifies the target data range and storage location to be exported, providing precise instruction basis for subsequent dump operations and ensuring the targeting and directionality of the dump operation.

[0084] S402, in response to the dump command, stores the dump data corresponding to the memory address to the device corresponding to the storage device identifier.

[0085] In some embodiments, in response to a dump command, storing the dump data corresponding to the memory address into the device corresponding to the storage device identifier may include: Retrieve the memory address and storage device identifier from the dump command; Determine the physical memory region of the dumped data based on the memory address; Read binary dump data from the physical memory region; Match the corresponding storage device driver and mount path based on the storage device identifier; Initialize the device according to the storage device driver and establish a data transmission channel; The read dump data is written in blocks to the designated storage area of ​​the storage device according to the data transmission channel; Based on the feedback information after the write operation is completed, the data integrity is verified, and finally the dump data corresponding to the memory address is stored in the device corresponding to the storage device identifier.

[0086] In some embodiments, the device corresponding to the storage device identifier may include an external storage device and a remote server. The external storage device may include a USB flash drive or an SD card.

[0087] This application embodiment stores the dump data at a specified memory address to the corresponding device in response to the dump command, realizing the complete export and retention of operating system crash scene data. It not only preserves the original state of the fault scene for offline analysis or cross-device reproduction, but also provides key data support for locating the root cause of the crash and repairing system defects. At the same time, the designated storage device ensures the security and accessibility of data storage.

[0088] This application embodiment achieves the targeted export and storage of specified memory data at the crash site by receiving a dump command containing a memory address and a storage device identifier. This preserves the original data at the crash site while ensuring data security and accessibility through the specified storage device. The exported data can be used for offline analysis and cross-device fault reproduction, making up for the limitations of on-site debugging, providing key data support for in-depth analysis of complex crash problems, and further improving the completeness of the debugging solution.

[0089] In some embodiments, the debugging method may further include: If an error is detected during the execution of a crash command, or if a user's target operation command is received, a central processing unit (CPU) exception message is generated.

[0090] In some embodiments, executing a crash command may include executing an invalid command. The user's target action command may include the user attempting an illegal operation, where an illegal operation may include writing to a read-only area.

[0091] In some embodiments, generating central processing unit (CPU) exception information may include: Prints the error messages that occurred during the execution of the crash command and the user's target operation command information.

[0092] This application's embodiments generate central processing unit (CPU) exception information upon detecting a crash command execution error or receiving a user's target operation command. This allows for the immediate capture of abnormal states during command execution, providing precise hardware-level clues for locating crash command execution failures. The exception information can trigger a pre-set error handling process within the system, preventing the error from spreading and causing further system crashes.

[0093] In some embodiments, such as Figure 5 As shown, the debugging methods may also include: S501 to S502.

[0094] S501, receive reset command.

[0095] It can receive input data from users through the crash command-line interactive interface.

[0096] In some embodiments, the reset command may include basic debugging commands built into the crash command-line interface.

[0097] This application embodiment, by receiving a reset command, clarifies the operation instructions for restoring the crashed command line environment, providing a trigger basis for subsequent context reset and command execution state restoration, ensuring timely response to the need for repairing environment anomalies during debugging.

[0098] In some embodiments, after receiving the reset command, the verification of the reset command may also be included.

[0099] In some embodiments, verifying the reset command may include: Retrieve the received reset command data; Extract command keywords, parameter formats, and permission identifiers from the reset command data; The matching result is obtained by verifying whether the command keyword matches the preset reset command identifier. Verify whether the reset granularity parameters, reserved item configurations, etc., conform to the syntax specifications according to the parameter format, and obtain the verification results; Verify whether the initiator has debugging permissions based on the permission identifier, and obtain the verification result; The validity of the reset command is determined by comprehensively considering the matching results, verification results, and check results, thus completing the verification of the reset command.

[0100] S502, in response to a reset command, resets the command line context to restore the crash command as an executable command.

[0101] In some embodiments, resetting the command line context may include: Obtain the verified reset command; The context reset granularity parameters and reserved item configurations are parsed based on the reset command; The command-line context dimension that needs to be reset is determined based on the reset granularity parameter; Lock the core debugging resources that need to be retained according to the reserved options configuration; Clear or restore the corresponding context data based on the determined reset dimension; Configure the retention options to retain core debugging resources and avoid duplicate loading; Verify the availability of the environment based on the context state after reset, complete the command line context reset, and restore the crashed command to an executable command.

[0102] In some embodiments, the reset granularity parameter may include full reset or precise reset.

[0103] The command-line context dimension can include the command parsing environment and error status flags.

[0104] Core debugging resources may include symbol tables and storage device mappings.

[0105] Clearing or restoring the corresponding context data can include resetting the parser state, clearing error codes, and restoring register initial values.

[0106] This application embodiment resets the command line context by responding to a reset command, effectively eliminating environmental disorder caused by previous command execution errors or abnormal operations, restoring crashed commands to an executable state, ensuring the availability and stability of the debugging environment, and allowing users to re-initiate the execution of crash-related commands and continue fault diagnosis work.

[0107] This application embodiment achieves rapid reset of the command line context by receiving and responding to reset commands, effectively eliminating environmental disorder caused by abnormal operations or command execution errors during debugging, and enabling crashed commands to quickly return to an executable state.

[0108] Figure 6 This application illustrates an operating system debugging device 600 provided in an embodiment of the present application. The device may include: The permission module 601 is used to modify the page table of the Memory Management Unit (MMU) when an operating system crash is detected, change the permissions of the code in the crash command segment to read and execute, change the permissions of the data in the crash command segment to read and write, and change the permissions of the operating system in the MMU page table to read only, so as to enter the crash command mode. The interaction module 602 is used to receive debugging commands input by the user and to debug the crashed operating system.

[0109] This application embodiment modifies the MMU page table when an operating system crash is detected, setting the code permissions in the crash command line segment to readable and executable, the data permissions to readable and writable, and the operating system permissions to read-only. This allows the code and data in the crash command line segment to be normally called and manipulated to enter the crash command line mode, while setting the operating system permissions to read-only prevents tampering with the original system data and state, thus effectively protecting the crash scene from destruction. The step of receiving user-inputted debugging commands and debugging the crashed operating system enables real-time interaction between the user and the debugging environment, supporting users to input debugging commands as needed for diagnosis, and realizing real-time interactive diagnosis.

[0110] In some embodiments, the device may further include: The debug command receiving module is used to receive debug commands input by the user and determine the target address corresponding to the access symbol through the symbol table in the code of the crash command line segment; wherein, the symbol table includes global access symbols that are allowed to be accessed by the crash command line, as well as the address of the data in the operating system kernel memory area corresponding to the access symbol; The target data reading module is used to read target data from the target address in the operating system kernel memory area; The system debugging execution module is used to debug a crashed operating system based on target data.

[0111] This application's embodiments utilize the built-in symbol table in the crash command line segment to achieve precise mapping between accessed symbols and target addresses in debugging commands. This clearly defines the range of allowed access to operating system kernel memory data, simplifying user debugging operations and eliminating the need to manually input complex physical addresses. Access control through the symbol table restricts debugging permission boundaries, preventing unauthorized access to sensitive system core data. Simultaneously, reading target address data supports debugging analysis, improving the accuracy and efficiency of crash scene data acquisition, which is beneficial for locating the root cause of the fault.

[0112] In some embodiments, the device may further include: The global symbol extraction module is used to extract global access symbols that are allowed to be accessed by the crash command line, as well as the addresses of the data in the operating system kernel memory area corresponding to the global access symbols, after the operating system compilation chain is completed. The symbol table generation module is used to generate a symbol table, which includes global access symbols and the correspondence between the addresses of the global access symbols. The symbol table linking module is used to compile and link symbol tables into the code of the crash command line.

[0113] This application embodiment extracts legal global access symbols and their corresponding kernel memory addresses during the operating system compilation stage, generates a symbol table, and links it to the crash command line code. This pre-sets the symbol mapping relationships required for debugging, avoiding the resource consumption and security risks of dynamically generating a symbol table after a crash. At the same time, by solidifying the symbol table during compilation, the accuracy and stability of symbol mapping are ensured, providing a reliable foundation for symbol-based address resolution and data access, and guaranteeing the smoothness and security of the debugging process.

[0114] In some embodiments, the device may further include: The initial MMU configuration module is used to configure the initial MMU page table during the normal startup process of the operating system. The permissions of the code and data in the crash command line segment in the initial MMU page table are configured to be unreadable, unwritable, and unexecutable.

[0115] This application embodiment configures the initial MMU page table during the normal operating system startup phase and sets the code and data permissions of the crash command line segment to be unreadable, unwritable, and unexecutable. This strictly restricts access to the crash command line segment during normal system operation, preventing it from being misoperated, maliciously tampered with, or accidentally executed, and avoiding interference with the normal operation of the system. At the same time, the crash command line segment is placed in an isolated protection state to ensure that it maintains its original integrity during normal system operation, laying a safe foundation for using this segment for debugging and diagnosis when the system crashes. This effectively isolates debugging functions from the normal system operation process, improving the stability and security of system operation.

[0116] In some embodiments, the device may further include: The dump command receiving module is used to receive dump commands, which include the memory address of the dump data and the storage device identifier of the dump data. The data dump execution module is used to respond to dump commands and store the dump data corresponding to the memory address to the device corresponding to the storage device identifier.

[0117] This application embodiment achieves the targeted export and storage of specified memory data at the crash site by receiving a dump command containing a memory address and a storage device identifier. This preserves the original data at the crash site while ensuring data security and accessibility through the specified storage device. The exported data can be used for offline analysis and cross-device fault reproduction, making up for the limitations of on-site debugging, providing key data support for in-depth analysis of complex crash problems, and further improving the completeness of the debugging solution.

[0118] In some embodiments, the device may further include: The exception information generation module is used to generate central processing unit exception information when an error is detected during the execution of a crash command or when a user's target operation command is received.

[0119] This application's embodiments generate central processing unit (CPU) exception information upon detecting a crash command execution error or receiving a user's target operation command. This allows for the immediate capture of abnormal states during command execution, providing precise hardware-level clues for locating crash command execution failures. The exception information can trigger a pre-set error handling process within the system, preventing the error from spreading and causing further system crashes.

[0120] In some embodiments, the device may further include: The reset command receiving module is used to receive reset commands; The reset command response module is used to reset the command line context in response to a reset command, so that the crashed command can be restored to an executable command.

[0121] This application embodiment achieves rapid reset of the command line context by receiving and responding to reset commands, effectively eliminating environmental disorder caused by abnormal operations or command execution errors during debugging, and enabling crashed commands to quickly return to an executable state.

[0122] Figure 7 A schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application is shown.

[0123] The terminal device may include a processor 701 and a memory 702 storing computer program instructions.

[0124] Specifically, the processor 701 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0125] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 702 may include removable or non-removable (or fixed) media, or memory 702 may be non-volatile solid-state memory. Memory 702 may be internal or external to the end device.

[0126] In one example, memory 702 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the debugging methods of the operating system according to this disclosure.

[0127] The processor 701 reads and executes computer program instructions stored in the memory 702 to achieve... Figure 1 The operating system debugging method in the illustrated embodiment.

[0128] In one example, the terminal device may also include a communication interface 703 and a bus 704. Wherein, for example... Figure 7 As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 704 and complete communication with each other.

[0129] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0130] Bus 704 includes hardware, software, or both, that couples components of an end device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 704 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0131] Furthermore, in conjunction with the operating system debugging methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the operating system debugging methods in the above embodiments.

[0132] This application also provides a computer program product, including a computer program that, when executed by a processor, implements a debugging method for any of the operating systems described in the above embodiments.

[0133] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0134] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or text segments used to perform the required tasks. Programs or text segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Text segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0135] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0136] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0137] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.< / device> < / end> < / start>

Claims

1. A debugging method of an operating system, characterized by, The operating system comprises a system memory area, the system memory area comprises a core memory area and an isolated memory area, the isolated memory area comprises a crash command line segment, the crash command line segment is used for storing codes and data of a debugging command line of the operating system crash, and the debugging method comprises the following steps: In the case that the operating system crash is detected, the memory management unit (MMU) page table is modified, the permission of the codes in the crash command line segment is modified to be readable and executable, the permission of the data in the crash command line segment is modified to be readable and writable, and the permission of the operating system in the MMU page table is modified to be read-only, so as to enter the crash command line mode; A user input debugging command is received, and the crashed operating system is debugged.

2. The commissioning method of claim 1, wherein, The debugging command comprises an access symbol; the receiving of the user input debugging command and the debugging of the crashed operating system comprise the following steps: A user input debugging command is received, and the target address corresponding to the access symbol is determined through a symbol table in the codes of the crash command line segment; wherein the symbol table comprises global access symbols allowed to be accessed by the crash command line, and the addresses of the data of the core memory area of the operating system corresponding to the access symbols; Target data in the target address of the core memory area of the operating system is read; The crashed operating system is debugged based on the target data.

3. The commissioning method of claim 2, wherein, Before the target address corresponding to the access symbol is determined through the symbol table, the debugging method further comprises the following steps: In the case that the operating system compilation chain is completed, global access symbols allowed to be accessed by the crash command line are extracted, and the addresses of the data of the core memory area of the operating system corresponding to the global access symbols are extracted; A symbol table is generated, the symbol table comprises the corresponding relationship between the global access symbols and the addresses corresponding to the global access symbols; The symbol table is compiled and linked into the codes of the crash command line.

4. The commissioning method of claim 1, wherein, Before the MMU page table is modified in the case that the operating system crash is detected, the debugging method further comprises the following steps: In the normal starting process of the operating system, an initial MMU page table is configured, and the permissions of the codes and the permissions of the data in the crash command line segment in the initial MMU page table are all configured to be unreadable, unwritable and unexecutable.

5. The commissioning method of claim 1, wherein, The debugging method further comprises the following steps: A dump command is received, the dump command comprises a memory address of dump data and a storage device identifier of the dump data; In response to the dump command, the dump data corresponding to the memory address is stored to the device corresponding to the storage device identifier.

6. The commissioning method of any of claims 1 to 5, wherein, The debugging method further comprises the following steps: In the case that an error occurs in the process of executing the crash command or a target operation command of a user is received, central processing unit (CPU) exception information is generated.

7. The commissioning method of claim 6, wherein, The debugging method further comprises the following steps: A reset command is received; In response to the reset command, the context of the command line is reset, so that the crash command is restored to an executable command.

8. A debugging apparatus of an operating system, characterized by comprising: The apparatus comprises: The permission module is configured to modify a memory management unit (MMU) page table to modify the permission of the code in the crash command line segment to be readable and executable, modify the permission of the data in the crash command line segment to be readable and writable, and modify the permission of the operating system in the MMU page table to be read-only, so as to enter the crash command line mode. The interaction module is configured to receive a debugging command input by a user and debug the crashed operating system.

9. A terminal device, comprising: The device comprises a processor and a memory storing computer program instructions; The processor executes the computer program instructions to implement the debugging method of the operating system according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the debugging method of the operating system according to any one of claims 1-7.

11. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the electronic device to enable the electronic device to implement the debugging method of the operating system according to any one of claims 1-7.

Images