Debugging method for kernel transplantation early process of LINUX operating system
By designing the print position and print content of the printk() function, and combining software simulation and hardware debugging, the problem of high learning difficulty and reliance on experience in early debugging methods for Linux operating system kernel porting was solved, and a simple and easy-to-use kernel debugging process was realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING MECHANICAL EQUIP INST
- Filing Date
- 2025-12-05
- Publication Date
- 2026-05-12
AI Technical Summary
In the early days of Linux operating system kernel porting, debugging methods were difficult to learn, required extensive developer experience, and were ineffective when hardware was not yet perfect.
By adopting a print position and print logic design based on the printk() function, and combining software simulation and hardware debugging, the kernel debugging process is simplified through kernel operation process analysis and error troubleshooting methods based on the print position and print content of the printk() function.
It lowers the difficulty of starting kernel porting, reduces reliance on software and hardware experience, provides a simple and easy-to-use approach to analysis, and improves the executability of kernel debugging.
Smart Images
Figure CN122019344A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of embedded operating system porting, and more specifically, to a method, apparatus, electronic device, and computer-readable storage medium for debugging the early process of porting a LINUX operating system kernel. Background Technology
[0002] Linux is a free and open-source Unix-like operating system. It is a POSIX-compliant, multi-user, multi-tasking operating system that supports multi-threading and multi-CPU. In the embedded field, it has been widely used due to its advantages such as being open source, stable, and having high operating efficiency.
[0003] The Linux operating system adopts a monolithic kernel architecture. The kernel is the key part of the Linux operating system, which can realize functions such as process management, memory management, file management, device management, and network management. The kernel provides a unified virtual machine interface to the upper level and implements the abstraction and management of hardware resources to the lower level.
[0004] Porting the Linux operating system to embedded boards can be divided into three steps: bootloader porting, kernel porting, and root file system porting. Kernel porting is the crucial step. The kernel porting process involves the development of hardware architecture code, driver code, and other related content, requiring extensive code analysis and debugging. Therefore, the design of debugging methods becomes critical. Current Linux operating system kernel debugging techniques include hardware-based in-circuit emulators (ICE) and on-chip debugging (OCD), as well as software-based source code simulators and debugging agents. However, in the early stages of Linux kernel porting, the kernel's core hardware configuration and control code were not yet complete, the minimal system could not boot, and the program would get stuck in kernel space. Using the aforementioned techniques for debugging presented certain difficulties and problems. Furthermore, the Linux kernel is highly complex, with inter-mechanism dependencies. In the early stages of kernel porting, when resources and information were limited, kernel debugging relied heavily on the developer's deep understanding of the kernel and extensive development experience, requiring a significant amount of knowledge and operational experience. In the early stages of kernel adaptation, with a mix of errors, beginners struggled to find a reasonable starting point when faced with complex kernel mechanisms and hardware-software interaction code with strong dependencies, making kernel porting too difficult to learn and rendering current debugging methods impractical.
[0005] Therefore, there is a need to study an early debugging method for Linux operating system kernel porting that is clear in steps, easy to learn, and simple to implement.
[0006] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0007] The purpose of this disclosure is to provide a method, apparatus, electronic device, and computer-readable storage medium for debugging the early stages of Linux operating system kernel porting, thereby overcoming, at least to some extent, one or more problems caused by limitations and defects in related technologies.
[0008] According to one aspect of this disclosure, a method for debugging the early stages of a Linux operating system kernel porting process is provided, comprising:
[0009] Design a kernel execution process analysis method based on the printk() function's print position and printing logic;
[0010] Design a kernel runtime error troubleshooting method based on the content printed by the printk() function;
[0011] Based on the kernel operation process analysis method and kernel operation error troubleshooting method, debugging is implemented in the early stages of Linux operating system kernel porting for embedded development boards.
[0012] In one exemplary embodiment of this disclosure, the kernel execution process analysis method based on the printk() function's print position and printing logic further includes:
[0013] Design the printing location and printing logic scheme for the printk() function;
[0014] Implement hardware and software deployment for the printk() function's printing location and printing logic scheme.
[0015] In one exemplary embodiment of this disclosure, the method further includes the design of the printing position and printing logic scheme for the printk() function:
[0016] The printk() function prints the program's execution flow, segmenting kernel functions and log information.
[0017] The key function of printk() is to enter the markup for printing;
[0018] The logical branch in the key function of printk() is marked for printing;
[0019] The printk() function prints the key data corresponding to the logical branches of the key functions.
[0020] The printk() function prints the call details and parameter passing information of its sub-functions within the key functions.
[0021] In one exemplary embodiment of this disclosure, the kernel runtime error troubleshooting method based on the content printed by the printk() function further includes:
[0022] Design a scheme for printing content using the printk() function;
[0023] Implement hardware and software deployment for the printk() function to print content.
[0024] In one exemplary embodiment of this disclosure, the method for designing the printk() function's print content further includes:
[0025] Design a troubleshooting scheme for printk() function errors based on program execution status;
[0026] Design a troubleshooting scheme for printk() function errors based on data flow.
[0027] In one aspect of this disclosure, a debugging apparatus for the early stages of porting a Linux operating system kernel is provided, comprising:
[0028] The runtime analysis module is used to design a kernel runtime analysis method based on the printk() function's print position and printing logic.
[0029] The runtime debugging module is used to design a method for debugging kernel runtime errors based on the content printed by the printk() function;
[0030] The porting and debugging module is used to perform debugging in the early stages of porting the Linux operating system kernel to an embedded development board, based on the kernel operation process analysis method and the kernel operation error troubleshooting method.
[0031] In one aspect of this disclosure, an electronic device is provided, comprising:
[0032] Processor; and
[0033] A memory storing computer-readable instructions that, when executed by the processor, implement the method according to any one of the preceding claims.
[0034] In one aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method according to any one of the preceding claims.
[0035] This disclosure discloses an exemplary embodiment of a debugging method for the early stages of Linux operating system kernel porting. The method includes: designing a kernel execution process analysis method based on the print position and logic of the printk() function; designing a kernel execution error troubleshooting method based on the print content of the printk() function; and implementing debugging in the early stages of Linux operating system kernel porting for embedded development boards based on the kernel execution process analysis method and the kernel execution error troubleshooting method. This disclosure unifies the analysis of hardware information input, software-hardware interaction, and internal kernel mechanisms into the analysis of data flow and processing methods, effectively extracting the main thread of kernel debugging analysis, reducing the software and hardware knowledge required in the early stages of kernel debugging, providing a simple and feasible starting analysis method, effectively reducing the difficulty of kernel porting and lowering the dependence on rich software and hardware experience in kernel porting.
[0036] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0037] The above and other features and advantages of this disclosure will become more apparent from the detailed description of exemplary embodiments thereof with reference to the accompanying drawings.
[0038] Figure 1 A flowchart is shown below illustrating a debugging method for the early stages of porting a Linux operating system kernel according to an exemplary embodiment of this disclosure;
[0039] Figure 2 A flowchart illustrating a kernel runtime analysis method based on the printk() function's print location and print logic design, according to an exemplary embodiment of this disclosure, is provided.
[0040] Figure 3 The flowchart illustrates a kernel runtime error troubleshooting method based on the printk() function's output, according to an exemplary embodiment of the present disclosure, for debugging the early process of Linux operating system kernel porting.
[0041] Figure 4 A schematic block diagram of an apparatus for debugging the early stages of a Linux operating system kernel porting process, according to an exemplary embodiment of the present disclosure, is shown.
[0042] Figure 5 A block diagram of an electronic device according to an exemplary embodiment of the present disclosure is shown schematically;
[0043] Figure 6 The illustration shows a schematic diagram of a computer-readable storage medium according to an exemplary embodiment of the present disclosure. Detailed Implementation
[0044] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.
[0045] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details described, or other methods, components, materials, apparatuses, steps, etc., can be employed. In other instances, well-known structures, methods, apparatuses, implementations, materials, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.
[0046] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, or in one or more software-hardened modules, or in different network and / or processor devices and / or microcontroller devices.
[0047] In this example embodiment, a debugging method for the early stages of Linux operating system kernel porting is first provided; see reference Figure 1 As shown, this method for debugging the early stages of a Linux operating system kernel porting process may include the following steps:
[0048] Step S110: Design a kernel execution process analysis method based on the printk() function's print position and printing logic;
[0049] Step S120: Design a kernel runtime error troubleshooting method based on the content printed by the printk() function;
[0050] Step S130: Based on the kernel operation process analysis method and kernel operation error troubleshooting method, debug the early process of Linux operating system kernel porting applied to embedded development boards.
[0051] This disclosure discloses an exemplary embodiment of a debugging method for the early stages of Linux operating system kernel porting. The method includes: designing a kernel execution process analysis method based on the print position and logic of the printk() function; designing a kernel execution error troubleshooting method based on the print content of the printk() function; and implementing debugging in the early stages of Linux operating system kernel porting for embedded development boards based on the kernel execution process analysis method and the kernel execution error troubleshooting method. This disclosure unifies the analysis of hardware information input, software-hardware interaction, and internal kernel mechanisms into the analysis of data flow and processing methods, effectively extracting the main thread of kernel debugging analysis, reducing the software and hardware knowledge required in the early stages of kernel debugging, providing a simple and feasible starting analysis method, effectively reducing the difficulty of kernel porting and lowering the dependence on rich software and hardware experience in kernel porting.
[0052] The following will further explain a method for debugging the early stages of LINUX operating system kernel porting in this example embodiment.
[0053] Example 1:
[0054] In step S110, a kernel execution process analysis method based on the printk() function's print position and printing logic can be designed.
[0055] In this example embodiment, the kernel execution process analysis method based on the printk() function's print position and printing logic further includes:
[0056] Design the printing location and printing logic scheme for the printk() function;
[0057] Implement hardware and software deployment for the printk() function's printing location and printing logic scheme.
[0058] In this example embodiment, the method further includes the design of the printing position and printing logic scheme for the printk() function:
[0059] The printk() function prints the program's execution flow, segmenting kernel functions and log information.
[0060] The key function of printk() is to enter the markup for printing;
[0061] The logical branch in the key function of printk() is marked for printing;
[0062] The printk() function prints the key data corresponding to the logical branches of the key functions.
[0063] The printk() function prints the call details and parameter passing information of its sub-functions within the key functions.
[0064] In step S120, a kernel runtime error troubleshooting method based on the content printed by the printk() function can be designed.
[0065] In this example embodiment, the kernel runtime error troubleshooting method based on the content printed by the printk() function further includes:
[0066] Design a scheme for printing content using the printk() function;
[0067] Implement hardware and software deployment for the printk() function to print content.
[0068] In this example embodiment, the method for designing the printk() function's print content further includes:
[0069] Design a troubleshooting scheme for printk() function errors based on program execution status;
[0070] Design a troubleshooting scheme for printk() function errors based on data flow.
[0071] In step S130, debugging can be carried out in the early stages of Linux operating system kernel porting applied to embedded development boards based on the kernel operation process analysis method and kernel operation error troubleshooting method.
[0072] In this example embodiment, software platform deployment refers to deploying the kernel-related parts of the aforementioned printk() function printing scheme. This involves debugging by controlling function input and output, and analyzing the function interactions and data flow states that the relevant mechanisms should possess under normal kernel operation. Hardware deployment refers to the analysis and debugging of the hardware to be debugged. Using the software deployment scheme provides observable successful running cases and richer debugging information for hardware debugging.
[0073] Example 2:
[0074] In this example embodiment, the debugging method disclosed herein for the early stages of Linux operating system kernel porting includes two aspects: a kernel runtime analysis method based on the print position and print logic design of the printk() function, and a kernel runtime error troubleshooting method based on the print content of printk(). These two aspects are performed in parallel; kernel runtime analysis provides theoretical guidance for kernel runtime error troubleshooting, while kernel runtime error troubleshooting provides practical feedback for kernel runtime analysis. The following describes the kernel runtime analysis method based on the print position and print logic design of the printk() function in detail based on Embodiment 1; and the kernel runtime error troubleshooting method based on the print content of printk() in detail based on Embodiment 2.
[0075] In the embodiments of this example, as Figure 2 The kernel runtime analysis method based on the printk() function's printing location and logic design comprises two parts: the design of the printk() function's printing location and logic scheme, and the hardware and software deployment analysis of the printk() function's printing scheme. The former provides a deployment plan for the latter, while the latter provides experiential feedback for the former. In actual debugging, the two complement each other and are used in parallel.
[0076] The printk() function's printing location and logic design include two aspects: printing the program's execution flow and printing the contents of key functions. A detailed description follows:
[0077] Program execution flow printing refers to adding multiple function print messages to a segment of a program based on the printk() function, thereby segmenting kernel functions and reflecting them in the kernel runtime log. By designing the printk() message printing positions, the log range corresponding to key functions can be clearly identified, thus aiding in the analysis of the actual role of specific functions and the specific events that occur before and after the function's execution.
[0078] The key function's output includes the following aspects:
[0079] Critical function entry marker printing refers to printing function entry markers at the beginning of critical functions based on printk() information. This shows the specific circumstances of the critical function being called by the kernel, thereby displaying the function's execution and call status during the overall kernel operation based on the kernel runtime log, and assisting in the analysis of kernel runtime logic.
[0080] The critical function logic branch entry mark printing refers to printing function information based on printk(). For critical functions containing important conditional branches, branch entry information is printed at the entry point of each branch statement to mark the specific jump situation of the program and its corresponding actual meaning, thereby analyzing the selection and judgment logic of the function's operation and assisting in the analysis of kernel operation logic.
[0081] Printing key data in critical function logic branches refers to printing the specific values of the entry, exit, and important internal data involved in the key logic branches of critical functions based on the printk() information printing function. This allows for further analysis of the specific logic and process details of the kernel entering that branch, thereby assisting in the understanding and sorting out of the kernel's running logic.
[0082] Printing critical function and sub-function call information and parameter passing details refers to printing function information based on printk() messages. For critical sub-functions within a critical function, call information and the entry data passed to the sub-function are printed before the function entry statement, thus assisting kernel analysis. This step can be performed as needed; it can print the relevant content of its sub-functions inside the critical function, or the sub-functions can be treated as independent critical functions and processed in the same way as the printk() content of independent critical functions.
[0083] The analysis of the hardware and software deployment of the printk() function printing scheme is divided into two aspects: software deployment and hardware deployment.
[0084] Software Deployment: Using the QEMU simulation platform, a virtual board capable of running the current kernel is selected from the platform's built-in virtual development board. Successful operation of this virtual board is achieved using QEMU. The hardware-independent parts of the designed `printk()` function are deployed to this virtual board. The kernel execution process is analyzed based on the successfully running simulation case. Even before successful execution on actual hardware, a more macroscopic analysis of the execution flow is obtained. The `printk()` function printing scheme needs to be adjusted according to the actual situation of the virtual board.
[0085] Hardware deployment: Deploy the above printk() function printing scheme on the actual development board, and analyze the kernel operation process based on the case under testing.
[0086] Combined use of software and hardware deployment schemes: In the early stages of Linux operating system kernel adaptation, the actual boards to be developed could not run the kernel system normally, and the complete kernel operation mechanism was difficult to observe. Therefore, successful software deployment cases were used to analyze the complete operation process of the relevant mechanisms, providing rich and comprehensive analysis and debugging information for hardware deployment. The two schemes were used for comparison.
[0087] In the embodiments of this example, as Figure 3 The kernel runtime error troubleshooting method based on the printk() function's output consists of two parts: the design of the printk() function's output scheme and the hardware and software deployment analysis of the printk() function's output scheme. The former provides a deployment plan for the latter, while the latter provides experiential feedback for the former. In actual debugging, the two complement each other and are used in parallel.
[0088] The design of the printk() function printing scheme includes: a printk() function printing error troubleshooting scheme based on program execution status and a printk() function printing error troubleshooting scheme based on data flow status.
[0089] This troubleshooting method for printk() function errors, based on program execution, involves locating the kernel error location and related information in the runtime log, searching the kernel source code to pinpoint the relevant key functions and data, and then printing the information using the printk() function. The results are then compared to the actual situation to determine the cause of the error.
[0090] Troubleshooting methods for printk() function errors based on data flow conditions include:
[0091] Printing key function inputs, outputs, and internal key data refers to printing the inputs, outputs, and internal key data of the key function based on the printk() information printing function and the related mechanisms involved in the error. Based on whether the key data matches the theoretical situation, it is determined whether there are problems with the function, the related content of the function, the related mechanism, and the associated mechanism of the related mechanism.
[0092] Printing specific instances of key data structures in relevant mechanisms refers to printing the specific values of key instances of key data structures in the relevant mechanisms involved in the error message, based on the printk() information printing function. By determining whether the specific values match the theoretical situation, it is judged whether there are problems in the data transmission process under the mechanism and its related mechanisms. By designing multiple printings of specific instances of key data structures, the specific links and functions where problems occur in the overall data flow process can be identified.
[0093] The analysis of the hardware and software deployment of the printk() function printing scheme is divided into two aspects: software deployment and hardware deployment.
[0094] Software Deployment: Using the QEMU simulation platform, a virtual board capable of running the current kernel is selected from the platform's built-in virtual development board. Successful operation of this virtual board is achieved using QEMU. The hardware-independent parts of the designed `printk()` function are deployed to this virtual board. The function interactions and data flow states of relevant mechanisms under normal kernel operation are analyzed to provide a reference for troubleshooting actual hardware. The `printk()` function printing scheme needs to be adjusted according to the actual situation of the virtual board.
[0095] Hardware deployment: Deploy the above printk() function printing scheme on the actual board to be developed, and troubleshoot the actual board cases that have problems or cannot run normally.
[0096] Combined use of software and hardware deployment solutions: Based on the software deployment solution, successful operation cases and richer debugging information are provided for hardware deployment to solve the problems of lack of reference and limited information access for hardware boards to be debugged or developed.
[0097] In this example embodiment, the present disclosure uses the printk() function to analyze the kernel operation process and troubleshoot kernel errors in the early stages of Linux operating system kernel porting. This effectively avoids the problems of limited available resources and debugging techniques in the early stages of kernel porting, and is technically simple and easy to learn. By reasonably designing the printing position, printing logic, and printing content of the printk() function, the kernel operation information and kernel error information that can be obtained through logs are enriched, effectively alleviating the debugging difficulties caused by insufficient log information in general. The method of combining software simulation and hardware debugging, as well as combining successful cases and cases to be adapted, provides a basis for Linux operating system kernel porting. Early on, it provided observable success cases and a more convenient software simulation analysis environment with less hardware dependence, effectively alleviating the debugging difficulties caused by insufficient debugging experience in the early stages. It focuses on debugging key data and key functions that operate on data in the Linux operating system kernel, analyzing system behavior from the perspective of data flow. It unifies the analysis of hardware information input, software and hardware interaction, and internal kernel mechanisms into the analysis of data flow and processing methods, effectively extracting the main thread of kernel debugging analysis, reducing the software and hardware knowledge required in the early stages of kernel debugging, providing a simple and feasible starting point for analysis, effectively reducing the difficulty of starting kernel porting, and reducing the dependence of kernel porting on rich software and hardware experience.
[0098] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.
[0099] Furthermore, this example embodiment also provides a debugging apparatus for the early stages of Linux operating system kernel porting. (See also...) Figure 4 As shown, the LINUX operating system kernel porting early process debugging device 400 may include: a runtime analysis module 410, a runtime troubleshooting module 420, and a porting debugging module 430. Wherein:
[0100] The runtime analysis module 410 is used to design a kernel runtime analysis method based on the printk() function's print position and printing logic.
[0101] Run the troubleshooting module 420, which is used to design a kernel runtime error troubleshooting method based on the content printed by the printk() function;
[0102] The porting and debugging module 430 is used to perform debugging in the early stages of porting the Linux operating system kernel to an embedded development board, based on the kernel operation process analysis method and the kernel operation error troubleshooting method.
[0103] The specific details of each of the above-mentioned Linux operating system kernel porting early process debugging device modules have been described in detail in the corresponding Linux operating system kernel porting early process debugging method, so they will not be repeated here.
[0104] It should be noted that although several modules or units of a LINUX operating system kernel porting early process debugging apparatus 400 are mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0105] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.
[0106] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented as entirely hardware embodiments, entirely software embodiments (including firmware, microcode, etc.), or embodiments combining hardware and software aspects, collectively referred to herein as “circuit,” “module,” or “system.”
[0107] The following reference Figure 5 To describe an electronic device 500 according to such an embodiment of the present invention. Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.
[0108] like Figure 5 As shown, the electronic device 500 is manifested in the form of a general-purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one storage unit 520, a bus 530 connecting different system components (including storage unit 520 and processing unit 510), and a display unit 540.
[0109] The storage unit stores program code that can be executed by the processing unit 510, causing the processing unit 510 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 510 can perform actions such as... Figure 1 Steps S110 to S130 are shown in the diagram.
[0110] Storage unit 520 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 5201 and / or cache memory 5202, and may further include a read-only memory (ROM) 5203.
[0111] Storage unit 520 may also include a program / utility 5204 having a set (at least one) program module 5205, such program module 5205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.
[0112] Bus 530 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.
[0113] Electronic device 500 can also communicate with one or more external devices 570 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 550. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 560. As shown, network adapter 560 communicates with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0114] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.
[0115] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the invention described in the "Exemplary Methods" section above.
[0116] refer to Figure 6 As shown, a program product 600 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.
[0117] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0118] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.
[0119] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.
[0120] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java and C++, and conventional procedural programming languages such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).
[0121] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.
[0122] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.
[0123] It should be understood that this disclosure is not limited to the precise structures 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 disclosure is limited only by the appended claims.
Claims
1. A debugging method for the early stages of Linux operating system kernel porting, characterized in that, The method includes: Design a kernel execution process analysis method based on the printing position and printing logic of the printk() function; Design a kernel runtime error troubleshooting method based on the content printed by the printk() function; Based on the kernel operation process analysis method and kernel operation error troubleshooting method, debugging is implemented in the early stages of Linux operating system kernel porting for embedded development boards.
2. The method as described in claim 1, characterized in that, The kernel execution process analysis method based on the printk() function's print position and printing logic also includes: Design the printing location and printing logic scheme for the printk() function; Implement hardware and software deployment for the printk() function's printing location and printing logic scheme.
3. The method as described in claim 2, characterized in that, The method also includes the following aspects regarding the design of the printk() function's printing location and printing logic scheme: The printk() function prints the program's execution flow, segmenting kernel functions and log information. The key function of printk() is to enter the markup for printing; The logical branch in the key function of printk() is marked for printing; The printk() function prints the key data corresponding to the logical branches of the key functions. The printk() function prints the call details and parameter passing information of the sub-functions within the key functions.
4. The method as described in claim 1, characterized in that, The kernel runtime error troubleshooting method based on the printk() function's output also includes: Design a scheme for printing content using the printk() function; Implement hardware and software deployment for the printk() function to print content.
5. The method as described in claim 4, characterized in that, The method for designing the printk() function's print content also includes: Design a troubleshooting scheme for printk() function errors based on program execution status; Design a troubleshooting scheme for printk() function errors based on data flow.
6. A debugging device for the early stages of Linux operating system kernel porting, characterized in that, The device includes: The runtime analysis module is used to design a kernel runtime analysis method based on the printk() function's print position and printing logic. The runtime debugging module is used to design a method for debugging kernel runtime errors based on the content printed by the printk() function; The porting and debugging module is used to perform debugging in the early stages of porting the Linux operating system kernel to an embedded development board, based on the kernel operation process analysis method and the kernel operation error troubleshooting method.
7. An electronic device, characterized in that, include Processor; and A memory storing computer-readable instructions that, when executed by the processor, implement the method according to any one of claims 1 to 5.
8. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 5.