Code debugging method and device, electronic equipment, storage medium and program product

Abstract

The invention relates to a code debugging method and device, electronic equipment, a storage medium and a program product. The code debugging is applied to a first electronic device, and the method comprises the steps that the name of a target to-be-debugged function in a target operation system running on a second electronic device and the name of a target debugging function are obtained; determining a target insertion position of the target debugging function in a code of the target operating system according to the name and a symbol table file of the target to-be-debugged function; determining a first address of the target debugging function in an executable file according to the name of the target debugging function and the symbol table file; and sending the target insertion position and the first address to the second electronic equipment.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a code debugging method, a code debugging device, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] With the rapid development of embedded systems and IoT devices, light kernel operating systems have been widely used due to their efficient resource management and small memory footprint. The design feature of light kernel is to simplify the structure of the operating system and only include necessary functional components to adapt to resource-constrained hardware environments. However, this design also brings certain limitations, especially in code debugging and performance analysis. Summary of the invention

[0003] The present invention provides a technical solution for code debugging.

[0004] According to one aspect of the present disclosure, a code debugging method is provided, the method being applied to a first electronic device, the method comprising:

[0005] Acquire the name of the target to-be-debugged function in the target operating system running on the second electronic device, and the name of the target debugging function;

[0006] Determine the target insertion position of the target debugging function in the code of the target operating system according to the name of the target to-be-debugged function and the symbol table file;

[0007] Determine the first address of the target debugging function in the executable file according to the name of the target debugging function and the symbol table file;

[0008] The target insertion position and the first address are sent to the second electronic device.

[0009] In a possible implementation, the method further includes:

[0010] The source code of the target operating system and the preset debugging function are compiled to generate the executable file and the symbol table file; wherein the function to be debugged of the target operating system includes an inserted null instruction; the function to be debugged includes the target function to be debugged, and the debugging function includes the target debugging function.

[0011] In a possible implementation, at least one empty instruction is inserted before and after the entry of the function body of the to-be-debugged function of the target operating system.

[0012] In a possible implementation, compiling the source code of the target operating system and the preset debugging function to generate the executable file and the symbol table file includes:

[0013] The source code of the target operating system and the preset debugging function are compiled as a whole to generate the executable file and the symbol table file.

[0014] In a possible implementation, the method further includes:

[0015] Sending coverage data to the second electronic device, wherein the coverage data is used to cover input data of the target function to be debugged.

[0016] In a possible implementation, a first preset buffer for buffering coverage data is provided in the first electronic device;

[0017] The sending the coverage data to the second electronic device includes:

[0018] The physical address of the first preset buffer is sent to the second electronic device, so that the second electronic device obtains the overwriting data according to the physical address of the first preset buffer.

[0019] In a possible implementation, the first electronic device is provided with a second preset buffer for buffering tracking data, further comprising:

[0020] Writing the trace data of the target debugging function from the second electronic device into the second preset buffer;

[0021] In response to the second preset buffer being full, generating a tracing data file in a preset format according to all tracing data in the second preset buffer, and clearing the second preset buffer.

[0022] In a possible implementation, the target operating system adopts a real-time operating system.

[0023] According to one aspect of the present disclosure, a code debugging method is provided, the method being applied to a second electronic device, the method comprising:

[0024] Acquire, from the first electronic device, a target insertion position of a target debugging function in a code of a target operating system, and a first address of the target debugging function in an executable file, wherein the target operating system represents an operating system running on the second electronic device;

[0025] Determine the virtual address of the target debugging function in the memory according to the first address;

[0026] The empty instruction corresponding to the target insertion position in the target function to be debugged is replaced with a jump instruction corresponding to the virtual address, wherein the jump instruction is used to jump to the target debugging function.

[0027] In a possible implementation, the method further includes:

[0028] In response to power-on, a portion of the target operating system in the executable file is mapped to a memory to start the target operating system; wherein, when the target operating system is started, a portion of the debugging function in the executable file remains in a non-mapped state.

[0029] In one possible implementation,

[0030] Determining the virtual address of the target debug function in the memory according to the first address includes: in response to determining that the virtual address in the memory has not been allocated for the target debug function according to the first address, allocating the virtual address to the target debug function;

[0031] The method further includes: copying the target debugging function from the executable file to the memory according to the first address, and establishing a mapping relationship between the physical address of the target debugging function in the memory and the virtual address.

[0032] In a possible implementation, the method further includes:

[0033] Acquire coverage data from the first electronic device;

[0034] The coverage data is used to cover the input data of the target function to be debugged.

[0035] In a possible implementation manner, the acquiring coverage data from the first electronic device includes:

[0036] Acquire, from the first electronic device, a physical address of a first preset buffer area in the first electronic device for buffering overlay data;

[0037] The coverage data is obtained from the first preset buffer according to the physical address of the first preset buffer.

[0038] In a possible implementation, the second electronic device is provided with a third preset buffer for buffering tracking data, further comprising:

[0039] Writing the trace data obtained by the target debugging function into the third preset buffer;

[0040] In response to the third preset buffer being full, all the tracking data in the third preset buffer are serially printed and the third preset buffer is cleared; or, in response to the third preset buffer being full, all the tracking data in the third preset buffer are sent to the first electronic device and the third preset buffer is cleared.

[0041] According to one aspect of the present disclosure, a code debugging device is provided, the device is applied to a first electronic device, and the device includes:

[0042] A first acquisition module, used to acquire the name of a target to-be-debugged function and the name of a target debugging function in a target operating system running on a second electronic device;

[0043] A first determining module, used for determining a target insertion position of the target debugging function in the code of the target operating system according to the name of the target function to be debugged and a symbol table file;

[0044] A second determining module, used for determining a first address of the target debugging function in the executable file according to the name of the target debugging function and the symbol table file;

[0045] The first sending module is used to send the target insertion position and the first address to the second electronic device.

[0046] In a possible implementation manner, the device further includes:

[0047] A compiling module is used to compile the source code of the target operating system and the preset debugging function to generate the executable file and the symbol table file; wherein the function to be debugged of the target operating system includes an inserted null instruction; the function to be debugged includes the target function to be debugged, and the debugging function includes the target debugging function.

[0048] In a possible implementation, at least one empty instruction is inserted before and after the entry of the function body of the to-be-debugged function of the target operating system.

[0049] In a possible implementation, the compiling module is used to:

[0050] The source code of the target operating system and the preset debugging function are compiled as a whole to generate the executable file and the symbol table file.

[0051] In a possible implementation manner, the device further includes:

[0052] The second sending module is used to send coverage data to the second electronic device, wherein the coverage data is used to cover the input data of the target function to be debugged.

[0053] In a possible implementation, a first preset buffer for buffering coverage data is provided in the first electronic device;

[0054] The second sending module is used for:

[0055] The physical address of the first preset buffer is sent to the second electronic device, so that the second electronic device obtains the overwriting data according to the physical address of the first preset buffer.

[0056] In a possible implementation, a second preset buffer for buffering tracking data is provided in the first electronic device, and the apparatus further includes:

[0057] A first writing module, configured to write the trace data of the target debugging function from the second electronic device into the second preset buffer;

[0058] The generating module is used for generating a tracing data file in a preset format according to all tracing data in the second preset buffer in response to the second preset buffer being full, and clearing the second preset buffer.

[0059] In a possible implementation, the target operating system adopts a real-time operating system.

[0060] According to one aspect of the present disclosure, a code debugging device is provided, the device is applied to a second electronic device, and the device includes:

[0061] A second acquisition module is used to acquire, from the first electronic device, a target insertion position of a target debugging function in a code of a target operating system, and a first address of the target debugging function in an executable file, wherein the target operating system represents an operating system running on the second electronic device;

[0062] A third determining module, configured to determine a virtual address of the target debugging function in the memory according to the first address;

[0063] The replacement module is used to replace the empty instruction corresponding to the target insertion position in the target function to be debugged with a jump instruction corresponding to the virtual address, wherein the jump instruction is used to jump to the target debugging function.

[0064] In a possible implementation manner, the device further includes:

[0065] A mapping module is used to map the target operating system portion in the executable file to the memory in response to power-on to start the target operating system; wherein, when the target operating system is started, the debug function portion in the executable file remains in a non-mapped state.

[0066] In one possible implementation,

[0067] The third determining module is used for: in response to determining, according to the first address, that the virtual address in the memory has not been allocated for the target debugging function, allocating the virtual address for the target debugging function;

[0068] The device further includes: a copy module, configured to copy the target debugging function from the executable file to the memory according to the first address, and to establish a mapping relationship between the physical address of the target debugging function in the memory and the virtual address.

[0069] In a possible implementation manner, the device further includes:

[0070] A third acquisition module, used to acquire coverage data from the first electronic device;

[0071] The coverage module is used to cover the input data of the target function to be debugged with the coverage data.

[0072] In a possible implementation manner, the third acquisition module is used to:

[0073] Acquire, from the first electronic device, a physical address of a first preset buffer area in the first electronic device for buffering overlay data;

[0074] The coverage data is obtained from the first preset buffer according to the physical address of the first preset buffer.

[0075] In a possible implementation, a third preset buffer for buffering tracking data is provided in the second electronic device, and the apparatus further includes:

[0076] A second writing module, used for writing the tracing data obtained by the target debugging function into the third preset buffer;

[0077] A serial port printing or sending module is used to, in response to the third preset buffer being full, perform serial port printing on all tracking data in the third preset buffer and clear the third preset buffer; or, in response to the third preset buffer being full, send all tracking data in the third preset buffer to the first electronic device and clear the third preset buffer.

[0078] According to one aspect of the present disclosure, an electronic device is provided, comprising: one or more processors; a memory for storing executable instructions; wherein the one or more processors are configured to call the executable instructions stored in the memory to execute the above method.

[0079] According to one aspect of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored, and the computer program instructions implement the above method when executed by a processor.

[0080] According to one aspect of the present disclosure, a computer program product is provided, including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in an electronic device, a processor in the electronic device executes the above method.

[0081] In an embodiment of the present disclosure, the name of the target function to be debugged in the target operating system running on the second electronic device is obtained by the first electronic device, and the name of the target debugging function, according to the name of the target function to be debugged and the symbol table file, the target insertion position of the target debugging function in the code of the target operating system is determined, according to the name of the target debugging function and the symbol table file, the first address of the target debugging function in the executable file is determined, and the target insertion position and the first address are sent to the second electronic device, thereby transferring the symbol table parsing to the first electronic device, and the second electronic device does not need to store the symbol table file and does not need to parse the symbol table, thereby saving the memory resources of the second electronic device. Moreover, compared with the traditional plug-in debugging method, the embodiment of the present disclosure can change the plug-in position at any time, and dynamically insert the debugging function into the function to be debugged, so as to achieve a more flexible and efficient debugging process. In addition, in the absence of debugging, the embodiment of the present disclosure can reduce the performance loss of the target operating system on the second electronic device when it is running normally. Therefore, the embodiment of the present disclosure can improve debugging efficiency, reduce resource consumption, and simplify the development process.

[0082] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

[0083] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and are used to illustrate the technical solutions of the present disclosure together with the specification.

[0085] Figure 1A flow chart of a code debugging method provided by an embodiment of the present disclosure is shown.

[0086] Figure 2 Another flow chart of the code debugging method provided by an embodiment of the present disclosure is shown.

[0087] Figure 3 A schematic diagram of a code debugging method provided by an embodiment of the present disclosure is shown.

[0088] Figure 4 Another schematic diagram of the code debugging method provided by an embodiment of the present disclosure is shown.

[0089] Figure 5 A block diagram of a code debugging device provided by an embodiment of the present disclosure is shown.

[0090] Figure 6 Another block diagram of the code debugging device provided by an embodiment of the present disclosure is shown.

[0091] Figure 7 A block diagram of an electronic device 1900 provided by an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0092] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0093] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0094] The term "and / or" herein is only a description of the association relationship of the associated objects, indicating that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" herein represents any combination of at least two of any one or more of a plurality of. For example, including at least one of A, B, and C can represent including any one or more elements selected from the set consisting of A, B, and C.

[0095] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present disclosure.

[0096] In the existing light kernel code framework, due to the strict restrictions on system resources, trace-related codes are rarely integrated. The trace function usually requires a large amount of symbol table and code space to record the runtime information of the program, which is often difficult to implement in resource-constrained light kernel systems. Therefore, traditional debugging methods mostly rely on manual stubbing, that is, developers need to debug each function one by one. This method is not only time-consuming, but also requires repeated compilation and burning of the code when the code is frequently modified, that is, "out of the mirror", resulting in low development and debugging efficiency.

[0097] In addition, the manual plug-in method has many inconveniences in actual operation. First, it requires developers to invest a lot of time to check and debug functions one by one, which is not only inefficient but also prone to errors. Secondly, each code modification is accompanied by the process of recompiling and burning, which not only increases the development cycle but also may cause system instability. Furthermore, frequent "out-of-image" operations will also affect the life of the storage medium and increase the maintenance cost of the system.

[0098] In order to solve the technical problems similar to those described above, the embodiment of the present disclosure provides a code debugging method, wherein the name of the target function to be debugged in the target operating system running on the second electronic device is obtained by the first electronic device, and the name of the target debugging function, and the target insertion position of the target debugging function in the code of the target operating system is determined according to the name of the target debugging function and the symbol table file, and the first address of the target debugging function in the executable file is determined according to the name of the target debugging function and the symbol table file, and the target insertion position and the first address are sent to the second electronic device, thereby transferring the symbol table parsing to the first electronic device, and the second electronic device does not need to store the symbol table file and does not need to parse the symbol table, thereby saving the memory resources of the second electronic device. Moreover, compared with the traditional plug-in debugging method, the embodiment of the present disclosure can change the plug-in position at any time, and dynamically insert the debugging function into the function to be debugged, so as to achieve a more flexible and efficient debugging process. In addition, in the absence of debugging, the embodiment of the present disclosure can reduce the performance loss of the target operating system on the second electronic device when it is running normally. Therefore, the embodiment of the present disclosure can improve debugging efficiency, reduce resource consumption, and simplify the development process.

[0099] The code debugging method provided by the embodiment of the present disclosure is described in detail below with reference to the accompanying drawings.

[0100] Figure 1A flow chart of a code debugging method provided by an embodiment of the present disclosure is shown. The execution subject of the code debugging method may be a first electronic device. In some possible implementations, the code debugging method may be implemented by a processor calling a computer-readable instruction stored in a memory. Figure 1 As shown, the code debugging method includes steps S11 to S14.

[0101] In step S11, the name of the target to-be-debugged function in the target operating system running on the second electronic device and the name of the target debugging function are obtained.

[0102] In step S12, a target insertion position of the target debugging function in the code of the target operating system is determined according to the name of the target function to be debugged and the symbol table file.

[0103] In step S13, the first address of the target debugging function in the executable file is determined according to the name of the target debugging function and the symbol table file.

[0104] In step S14, the target insertion position and the first address are sent to the second electronic device.

[0105] In the disclosed embodiment, the first electronic device may be a computer for development, testing and debugging. The first electronic device may run an operating system such as Windows, Linux or macOS. In addition, the first electronic device may have a more powerful processing capability and more resources (such as CPU processing capability, memory, etc.) than the second electronic device. In the disclosed embodiment, the first electronic device may run a debugging tool (such as mtc_tool).

[0106] The second electronic device may be an electronic device with limited resources (eg, CPU processing power, memory, etc.). The operating system running on the second electronic device may be referred to as a target operating system.

[0107] In a possible implementation, the target operating system adopts a real-time operating system (Real-Time Operating System, RTOS).

[0108] In this implementation, the first electronic device may be referred to as a host end or a host side, and the second electronic device may be referred to as an RTOS end or a RTOS side.

[0109] In this implementation, the second electronic device can respond to tasks within a specified time by adopting a real-time operating system, which is very important for application scenarios that require strict time control.

[0110] In other possible implementations, the target operating system may also adopt a lightweight embedded operating system, such as FreeRTOS, μC / OS-II, etc., which is not limited here.

[0111] In a possible implementation, the method further includes: compiling the source code of the target operating system and a preset debugging function to generate the executable file and the symbol table file; wherein the function to be debugged of the target operating system includes an inserted null instruction; the function to be debugged includes the target function to be debugged, and the debugging function includes the target debugging function.

[0112] The debugging function may refer to a function used for debugging purposes. The debugging function may be used to track program execution, monitor the state of variables, record performance data, etc., for use in the development and testing phases.

[0113] In this implementation, before obtaining the name of the target function to be debugged in the target operating system running on the second electronic device, the source code of the target operating system and the preset debugging function can be compiled to generate an executable file and a symbol table file. The executable file can be used to run on the second electronic device. The symbol table file can include address information of the function in the target operating system and address information of the debugging function.

[0114] In this implementation, the function to be debugged in the target operating system may represent a function to be debugged in the target operating system. The function to be debugged in the target operating system may be manually executed, or may be automatically determined according to actual debugging requirements, which is not limited here.

[0115] In this implementation, during the compilation process, empty instructions (such as NOP instructions) are inserted into the function to be debugged of the target operating system. These empty instructions occupy a certain space in the compiled code, but do not perform any operation. Their existence is to be able to insert the debug function in the subsequent steps. That is, the position of the empty instruction can be used to insert the debug function. And, in the case where the debug function does not need to be inserted, the existence of the empty instruction has no effect on the performance of the target operating system.

[0116] In this implementation, after the executable file is generated, the executable file may be stored in a non-volatile memory (eg, flash memory) of the second electronic device.

[0117] In this implementation, after the symbol table file is generated, the symbol table file can be stored in the first electronic device. In this implementation, the symbol table file does not need to be stored in the second electronic device, thereby saving storage space of the second electronic device.

[0118] In this implementation, by inserting null instructions in the function to be debugged in advance during the compilation phase, the debug function can be dynamically inserted into these reserved locations without modifying the compiled code. This implementation can flexibly enable or disable the debugging function at runtime without recompiling the entire target operating system.

[0119] In a possible implementation, at least one empty instruction is inserted before and after the entry of the function body of the to-be-debugged function of the target operating system.

[0120] In this implementation, when compiling the source code of the target operating system, null instructions are embedded before and after the entry of the function body of the function to be debugged. When the target operating system is running, the debugging function can be dynamically inserted into these reserved null instruction positions as needed. In this way, when the target operating system runs to these positions, the debugging function can be executed to monitor or change the behavior of the target operating system.

[0121] As an example of this implementation, at least two empty instructions may be inserted before and after the entry of the function body of the function to be debugged in the target operating system.

[0122] This implementation provides a flexible debugging method, allowing developers to dynamically insert and remove debugging code without recompiling the entire target operating system. Since null instructions do not affect the normal logic and performance of the target operating system, the debugging function can be easily activated or deactivated when the target operating system is running. In addition, this implementation reduces the modification of the code of the target operating system during the debugging process, thereby reducing the risk of introducing new errors (bugs), and makes the debugging process more efficient because it allows developers to focus on specific debugging points instead of scattering debugging code throughout the code. Therefore, this implementation can improve the flexibility and efficiency of debugging while maintaining the stability and performance of the target operating system.

[0123] In a possible implementation manner, there are multiple debugging functions.

[0124] For example, the preset debugging functions may include func1, func2, func3, and func4.

[0125] In this implementation, multiple debugging functions can be selected according to different debugging requirements, so that debugging can be performed more flexibly.

[0126] In a possible implementation, compiling the source code of the target operating system and the preset debugging function to generate the executable file and the symbol table file includes: compiling the source code of the target operating system and the preset debugging function as a whole to generate the executable file and the symbol table file.

[0127] Monolithic compilation is a compilation strategy that involves compiling all the source code files of the entire program together into a single executable file. This approach is in contrast to file-by-file compilation or incremental compilation, which compiles only modified files or compiles each file individually.

[0128] In this implementation, the source code of the target operating system and the preset debugging function can be compiled as a whole. Before compilation, the source code of the target operating system and the preset debugging function can be integrated together. That is, the source code of the target operating system and the preset debugging function can be regarded as a single compilation unit. The compiler processes the entire integrated code and performs a series of compilation steps such as syntax analysis, semantic analysis, optimization and code generation. Since the compiler can see the code of the entire program, it can perform more in-depth analysis and optimization, such as inline function calls across files, global optimization, etc.

[0129] In this implementation, compiling the target operating system's source code and preset debugging functions as a whole can improve compilation consistency and efficiency, ensure the accuracy of generated executable files and symbol table files, simplify the debugging process, and reduce the complexity of configuration and maintenance.

[0130] In another possible implementation, the source code of the target operating system and the preset debugging function may be compiled separately.

[0131] In another possible implementation, the source code of the target operating system and the preset debugging function can be compiled in an electronic device other than the first electronic device. For example, the source code of the target operating system and the preset debugging function can be compiled on a dedicated compilation server. In the case where the source code of the target operating system and the preset debugging function are compiled in an electronic device other than the first electronic device, after the symbol table file is generated, the symbol table file can be copied to the first electronic device so that the first electronic device can search for the function address (e.g., the address of the function to be debugged and the address of the debugging function) based on the symbol table file.

[0132] In the embodiment of the present disclosure, the target function to be debugged may represent a function to be debugged specified by a user among functions to be debugged of the target operating system, and the target debugging function may represent a debugging function selected by a user among multiple debugging functions.

[0133] In an embodiment of the present disclosure, the first electronic device can search the symbol table file according to the name of the target function to be debugged, determine the position of the empty instruction in the target function to be debugged, and determine the target insertion position according to the position of the empty instruction in the target function to be debugged. The target insertion position can represent the position for inserting the target debug function.

[0134] The first electronic device can search the symbol table file according to the name of the target debugging function to determine the first address of the target debugging function in the executable file, wherein the first address can represent the address of the target debugging function in the executable file.

[0135] In a possible implementation, the debugging tool mtc_tool in the first electronic device can find the target insertion position of the target debugging function in the code of the target operating system and the first address of the target debugging function in the executable file in the symbol table file through the command line tool readelf.

[0136] After determining the target insertion position and the first address, the first electronic device can send the target insertion position and the first address to the second electronic device. In a possible implementation, the first electronic device can put the target insertion position and the first address into an IPC (Inter-Process Communication) message to transmit the target insertion position and the first address to the second electronic device via the IPC message.

[0137] In a possible implementation manner, the method further includes: sending coverage data to the second electronic device, wherein the coverage data is used to cover input data of the target function to be debugged.

[0138] In this implementation, a coverage data file may be created in the first electronic device. The coverage data file may include coverage data for covering the input data of the target function to be debugged. The type of coverage data may be flexibly determined according to the type of input data of the target function to be debugged. For example, the type of coverage data may include power consumption, temperature, utilization rate, etc., which are not limited here.

[0139] As an example of this implementation, the coverage data file may include multiple sets of coverage data. For example, the coverage data file may include multiple sets of power consumption data and temperature data, so as to cover the input data of the target function to be debugged with different sets of power consumption data and temperature data in multiple runs of the target function to be debugged, and obtain corresponding tracking data.

[0140] As an example of this implementation, the coverage data file may further include type information of the data to be tracked.

[0141] In this implementation, by sending coverage data to the second electronic device, wherein the coverage data is used to cover the input data of the target function to be debugged, the input data of the target function to be debugged can be dynamically replaced, saving time for repeated debugging. In the case where the coverage data includes temperature data and power consumption data, the input data of the target function to be debugged is replaced by the coverage data, thereby eliminating the need to place the second electronic device in a temperature-controlled environment, thereby saving the temperature-controlled environment. Among them, the temperature-controlled environment can represent an environment for increasing or decreasing the ambient temperature of the second electronic device.

[0142] In a possible implementation, a first preset buffer for buffering overlay data is provided in the first electronic device; sending the overlay data to the second electronic device includes: sending a physical address of the first preset buffer to the second electronic device, so that the second electronic device obtains the overlay data according to the physical address of the first preset buffer.

[0143] In this implementation, a specific buffer, namely, a first preset buffer, is set in the first electronic device. The main function of the first preset buffer is to buffer overwrite data. When it is necessary to send overwrite data to the second electronic device, the first electronic device does not directly send the overwrite data itself, but sends the physical address of the first preset buffer. After receiving the physical address of the first preset buffer, the second electronic device can access and obtain the overwrite data in the first electronic device according to the physical address of the first preset buffer.

[0144] In this implementation, the first electronic device can parse the overlay data file and put the overlay data in the overlay data file into the first preset buffer. For example, the debugging tool mtc_tool in the first electronic device can parse the power consumption data overlay_power and the temperature data overlay_temp in the overlay data file overlay.csv, put the power consumption data overlay_power and the temperature data overlay_temp in the overlay data file overlay.csv into the first preset buffer, and put the physical address of the first preset buffer into the IPC message.

[0145] In this implementation, by sending the physical address of the first preset buffer instead of the overwriting data itself, the second electronic device can autonomously obtain the overwriting data according to the physical address of the first preset buffer without waiting for the first electronic device to send it.

[0146] As an example of this implementation, the first preset buffer may be a continuous data space, which is helpful to improve the access speed of the overlay data, that is, it is helpful to improve the speed at which the second electronic device acquires the overlay data.

[0147] In the disclosed embodiment, when the target operating system runs to a jump instruction, it will jump to execute the target debugging function. For a null instruction without a debugging function, the null instruction can be executed, thereby saving performance overhead.

[0148] In a possible implementation, a second preset buffer for buffering tracing data is provided in the first electronic device, and the method further includes: writing the tracing data of the target debugging function from the second electronic device into the second preset buffer; in response to the second preset buffer being full, generating a tracing data file in a preset format according to all the tracing data in the second preset buffer, and clearing the second preset buffer.

[0149] As an example of this implementation, the first electronic device may create a second preset buffer for buffering the tracing data through the debugging tool mtc_tool.

[0150] As an example of this implementation, the second preset buffer may be a circular buffer.

[0151] The types of tracking data may also vary depending on the actual application scenario. For example, the tracking data may include current power consumption, current temperature, current clock frequency, etc., which are not limited here.

[0152] As an example of this implementation, the first electronic device may put the physical address of the second preset buffer into an IPC message to send the physical address of the second preset buffer to the second electronic device.

[0153] In this implementation, a second preset buffer is set in the first electronic device for temporarily storing the tracing data of the target debugging function received from the second electronic device. As the tracing data is continuously written, when the second preset buffer is full, a tracing data file in a preset format can be generated based on all the tracing data accumulated in the second preset buffer. After the tracing data file in the preset format is generated, the second preset buffer will be cleared to continue to receive new tracing data, thereby realizing continuous processing and storage of tracing data.

[0154] This implementation provides an effective tracking data processing mechanism. By setting the second preset buffer, the tracking data is collected and temporarily stored. By generating a tracking data file in a preset format, the storage and subsequent analysis of the tracking data are facilitated, and the efficiency and accuracy of the debugging work are improved. In addition, the clearing operation of the second preset buffer ensures the continuity of the tracking data processing, so that the entire process can be carried out continuously and stably.

[0155] Figure 2Another flow chart of the code debugging method provided by the embodiment of the present disclosure is shown. The execution subject of the code debugging method may be a second electronic device. The operating system running on the second electronic device may be called a target operating system.

[0156] In step S21, a target insertion position of a target debugging function in a code of a target operating system and a first address of the target debugging function in an executable file are obtained from the first electronic device, wherein the target operating system represents an operating system running on the second electronic device.

[0157] In step S22, the virtual address of the target debugging function in the memory is determined according to the first address.

[0158] In step S23, the empty instruction corresponding to the target insertion position in the target function to be debugged is replaced with a jump instruction corresponding to the virtual address, wherein the jump instruction is used to jump to the target debugging function.

[0159] In a possible implementation, before acquiring the target insertion position of the target debugging function in the code of the target operating system from the first electronic device, the method further includes: storing the executable file in a non-volatile memory.

[0160] In this implementation, after the executable file is generated, the executable file may be stored in a non-volatile memory of the second electronic device. For example, the executable file may be stored in a flash memory of the second electronic device.

[0161] In this implementation, by storing the executable file in the non-volatile memory of the second electronic device, the persistence of the executable file can be ensured. Even when the power of the second electronic device is turned off, the non-volatile memory of the second electronic device, such as flash memory, can still maintain the stored executable file, thereby preventing data loss caused by sudden power failure or system crash.

[0162] In one possible implementation, the method further includes: in response to power-on, mapping a portion of the target operating system in the executable file to memory to start the target operating system; wherein, when the target operating system is started, a portion of the debug function in the executable file remains in a non-mapped state.

[0163] In this implementation, when the second electronic device is started, the memory management unit (MMU) of the second electronic device may only map the target operating system portion in the executable file to the memory, and retain the debug function portion in the executable file in the non-volatile memory. That is, when the second electronic device is started, the debug function portion in the executable file may not be mapped to the memory.

[0164] For example, when the second electronic device is started, the memory management unit of the second electronic device may map a portion of the target operating system in the executable file to a static random access memory (SRAM).

[0165] In this implementation, the debugging function in the executable file is mapped to the memory of the second electronic device only when it is needed. For example, when the debugging tool mtc_tool in the first electronic device tells it to be used, the debugging function in the executable file is mapped to the memory of the second electronic device, thereby saving memory resources of the second electronic device.

[0166] In an embodiment of the present disclosure, the second electronic device obtains the target insertion position of the target debugging function in the code of the target operating system and the first address of the target debugging function in the executable file from the first electronic device. In a possible implementation, the second electronic device can obtain the target insertion position and the first address from the first electronic device through an IPC message.

[0167] In an embodiment of the present disclosure, the second electronic device may determine a virtual address of the target debugging function in the memory according to the first address.

[0168] In a possible implementation, when it is determined according to the first address that a virtual address in the memory has been allocated to the target debugging function, the virtual address may be directly acquired.

[0169] In another possible implementation, determining the virtual address of the target debugging function in the memory according to the first address includes: in response to determining, according to the first address, that the virtual address in the memory has not been allocated to the target debugging function, allocating the virtual address to the target debugging function; the method further includes: copying the target debugging function from the executable file to the memory according to the first address, and establishing a mapping relationship between the physical address of the target debugging function in the memory and the virtual address.

[0170] In this implementation, when the first electronic device attempts to determine the virtual address of the target debug function in the memory according to the first address, if it is found that the virtual address has not been assigned to the target debug function, the virtual address assignment process can be automatically triggered. This assignment process ensures that the target debug function has a corresponding virtual address space in the memory for use when it is executed. In this implementation, the first electronic device can also find the code of the target debug function from the executable file according to the first address and copy it to the memory. In addition, in order to ensure that the target operating system can correctly access the target debug function, the first electronic device can also establish a mapping relationship between the physical address of the target debug function in the memory and the virtual address.

[0171] As an example of this implementation, the target debug function may be copied from the non-volatile memory to a preset debug function area (eg, patch_area) in the SRAM.

[0172] In one example, the maximum amount of data among the preset amounts of data of the plurality of debug functions may be determined, and the capacity of the preset debug function area may be determined based on the maximum amount of data. For example, the capacity of the preset debug function area may be slightly larger than the maximum amount of data. For another example, the capacity of the preset debug function area may be equal to the maximum amount of data.

[0173] In one example, the RTOS can replace the empty instruction corresponding to the target insertion position trace_point with the jump instruction corresponding to the virtual address of the target debug function trace_func, and refresh the CPU's Dcache and icache. At this time, since the target debug function trace_func is placed in the flash memory and has not yet been copied to the memory, an MMU abnormal interrupt will occur when accessing the virtual address of the target debug function trace_func. In the abnormal interrupt, the target debug function trace_func can be copied from the flash memory to the preset debug function area patch_area in the SRAM, and the MMU mapping can be re-performed. At this time, the virtual address of the target debug function trace_func can be accessed normally.

[0174] This implementation method realizes the dynamic loading and memory management of the target debug function. By automatically allocating virtual addresses and copying the function code of the target debug function from the executable file, it ensures that the target debug function can be successfully loaded into the memory and ready for execution. At the same time, the mapping relationship between the physical address and the virtual address is established to ensure that the target operating system can accurately access the target debug function.

[0175] In a possible implementation manner, the method further includes: acquiring coverage data from the first electronic device; and using the coverage data to cover input data of the target function to be debugged.

[0176] The type of coverage data can be flexibly determined according to the type of input data of the target function to be debugged. For example, the type of coverage data can include power consumption, temperature, utilization rate, etc., which are not limited here.

[0177] In this implementation, the second electronic device obtains coverage data from the first electronic device, and uses the coverage data to cover the input data of the target function to be debugged, thereby dynamically replacing the input data of the target function to be debugged, saving time for repeated debugging. In the case where the coverage data includes temperature data and power consumption data, the input data of the target function to be debugged is replaced by the coverage data, thereby eliminating the need to place the second electronic device in a temperature-controlled environment, thereby saving the temperature-controlled environment. Among them, the temperature-controlled environment can represent an environment for increasing or decreasing the ambient temperature of the second electronic device.

[0178] In a possible implementation, obtaining coverage data from the first electronic device includes: obtaining from the first electronic device a physical address of a first preset buffer in the first electronic device for buffering coverage data; and obtaining the coverage data from the first preset buffer according to the physical address of the first preset buffer.

[0179] In this implementation, by obtaining the physical address of the first preset buffer for buffering overlay data in the first electronic device rather than the overlay data itself from the first electronic device, the second electronic device can autonomously obtain the overlay data based on the physical address of the first preset buffer without waiting for the first electronic device to send it.

[0180] In a possible implementation, a third preset buffer for buffering tracing data is provided in the second electronic device, and the method further includes: writing the tracing data obtained by the target debugging function into the third preset buffer; in response to the third preset buffer being full, printing all tracing data in the third preset buffer through a serial port and clearing the third preset buffer, or, in response to the third preset buffer being full, sending all tracing data in the third preset buffer to the first electronic device and clearing the third preset buffer.

[0181] In this implementation, a third preset buffer is set in the second electronic device for temporarily storing the tracing data obtained by the target debugging function. That is, when the target debugging function generates tracing data, the tracing data will be written into the third preset buffer. When the third preset buffer is full, the second electronic device can output all the tracing data in the third preset buffer by serial port printing, and clear the buffer to receive new tracing data. Alternatively, when the third preset buffer is full, the tracing data in the third preset buffer can be sent to the first electronic device, and the third preset buffer can be cleared after sending.

[0182] In this implementation, the second electronic device may send all the tracking data in the third preset buffer to the first electronic device at once after the third preset buffer is full, thereby reducing the number of times of reporting tracking data.

[0183] As an example of this implementation, if the debugging tool mtc_tool in the first electronic device does not open a window for collecting tracking data, the second electronic device may not send the tracking data to the first electronic device to reduce data transmission.

[0184] The following describes the code debugging method provided by the embodiment of the present disclosure through a specific application scenario. Figure 3 A schematic diagram of a code debugging method provided by an embodiment of the present disclosure is shown. Figure 4 Another schematic diagram of the code debugging method provided by the embodiment of the present disclosure is shown. In this application scenario, the debugging tool mtc_tool may be run on the first electronic device, and the target operating system running on the second electronic device may be RTOS.

[0185] In the first step, the source code of the RTOS and a set of preset debugging functions func1, func2, func3 and func4 can be compiled as a whole to generate an executable file and a symbol table file mt_fw.elf. In the compilation process, at least two empty instructions can be inserted before and after the entry of the function body of the function to be debugged (such as APP1 and APP2) in the RTOS. After the executable file is generated, the executable file can be stored in the flash memory of the second electronic device.

[0186] In the second step, when the second electronic device starts, the MMU of the second electronic device may only map the RTOS portion in the executable file to the SRAM, but not map the debug function portion in the executable file to the SRAM.

[0187] In the third step, when the overall compilation is completed in an electronic device other than the first electronic device (eg, a dedicated compilation server), the symbol table file mt_fw.elf generated by the overall compilation can be copied to the first electronic device.

[0188] In the fourth step, an overlay data file overlay.csv may be created in the first electronic device. The overlay data file may include overlay data for overwriting the input data of the target function to be debugged. Figure 3 and Figure 4 In the example shown, the overlay data includes power consumption data overlay_power and temperature data overlay_temp.

[0189] In the fifth step, you can set the name of the target function to be debugged (for example, APP1) track_func_name, the target debugging function (for example Figure 3 func2 in or Figure 4 The name trace_func_name in the trace_func file, the symbol table file mt_fw.elf, and the overlay data file overlay.csv are passed to the debugging tool mtc_tool for data parsing.

[0190] In the sixth step, the debugging tool mtc_tool can find the target insertion position trace_point of the target debugging function (such as trace_func) in the RTOS code in the symbol table file mt_fw.elf through the command line tool readelf, and can put the target insertion position trace_point into the IPC message.

[0191] In step 7, the debugging tool mtc_tool can parse the power consumption data overlay_power and the temperature data overlay_temp in the overlay data file overlay.csv, and put the power consumption data overlay_power and the temperature data overlay_temp in the overlay data file overlay.csv into the first preset buffer (for example Figure 3 and Figure 4 , and put the physical address overlay_addr of the first preset buffer into the IPC message.

[0192] In step 8, the debugging tool mtc_tool can create a second preset buffer for buffering the tracking data (eg Figure 3 and Figure 4 The map_buffer below in the memory) and the physical address ring_buffer_addr of the second preset buffer can be put into the IPC message.

[0193] In the ninth step, the debugging tool mtc_tool may send an IPC message to the RTOS, and the RTOS may map the physical address of the first preset buffer and the physical address of the second preset buffer to the virtual address space.

[0194] In the tenth step, the RTOS can replace the empty instruction corresponding to the target insertion position trace_point with the jump instruction corresponding to the virtual address of the target debugging function trace_func (for example Figure 3 bl in the memory) and refresh the CPU's Dcache and icache. At this time, since the target debug function trace_func has not been copied to the memory, an MMU exception interrupt will occur when accessing the virtual address of the target debug function trace_func. In the exception interrupt, the target debug function trace_func can be copied from the flash memory to the preset debug function area patch_area in the SRAM, and the MMU mapping can be re-performed. At this time, the virtual address of the target debug function trace_func can be accessed normally.

[0195] If other debugging functions are needed, the previous debugging functions in the preset debugging function area patch_area can be cleared, and the new debugging functions can be copied to the preset debugging function area patch_area.

[0196] Step 11: When the RTOS runs to the jump instruction (for example, Figure 4 As shown in FIG. 1 , when pm_running runs to a jump instruction, it will jump to execute the target debug function trace_func. For empty instructions without a debug function, empty instructions can be executed, thereby saving performance overhead.

[0197] In step 12, the target debugging function trace_func can use the overlay data (such as power consumption data overlay_power and temperature data overlay_temp) to replace the input data of the target function to be debugged. In addition, the target debugging function trace_func can collect the tracking data track_datea (such as current power consumption power, current temperature temp, current clock frequency clock), and can put the tracking data into the third preset buffer track_data_buffer.

[0198] Step 13: When the third preset buffer is full, all the tracking data in the third preset buffer can be printed through the serial port, and the third preset buffer can be cleared. If the debugging tool mtc_tool opens a window for collecting tracking data, all the tracking data can be sent to the second preset buffer.

[0199] In step 14, when the second preset buffer is full, the debugging tool mtc_tool can organize all the tracking data in the second preset buffer into a data list, and output it to the tracking data file output.csv.

[0200] It can be understood that the above-mentioned various method embodiments mentioned in the present disclosure can be combined with each other to form a combined embodiment without violating the principle logic. Due to space limitations, the present disclosure will not repeat them. It can be understood by those skilled in the art that in the above-mentioned method of the specific implementation method, the specific execution order of each step should be determined according to its function and possible internal logic.

[0201] In addition, the present disclosure also provides a code debugging device, an electronic device, a computer-readable storage medium, and a computer program product, all of which can be used to implement any code debugging method provided by the present disclosure. The corresponding technical solutions and technical effects can be found in the corresponding records in the method part and will not be repeated here.

[0202] Figure 5 A block diagram of a code debugging device provided by an embodiment of the present disclosure is shown. The device is applied to a first electronic device. Figure 5 As shown, the code debugging device includes:

[0203] A first acquisition module 51 is used to acquire the name of a target to-be-debugged function and the name of a target debugging function in a target operating system running on a second electronic device;

[0204] A first determining module 52, configured to determine a target insertion position of the target debugging function in the code of the target operating system according to the name of the target function to be debugged and the symbol table file;

[0205] A second determining module 53, used for determining a first address of the target debugging function in the executable file according to the name of the target debugging function and the symbol table file;

[0206] The first sending module 54 is used to send the target insertion position and the first address to the second electronic device.

[0207] In a possible implementation manner, the device further includes:

[0208] A compiling module is used to compile the source code of the target operating system and the preset debugging function to generate the executable file and the symbol table file; wherein the function to be debugged of the target operating system includes an inserted null instruction; the function to be debugged includes the target function to be debugged, and the debugging function includes the target debugging function.

[0209] In a possible implementation, at least one empty instruction is inserted before and after the entry of the function body of the to-be-debugged function of the target operating system.

[0210] In a possible implementation, the compiling module is used to:

[0211] The source code of the target operating system and the preset debugging function are compiled as a whole to generate the executable file and the symbol table file.

[0212] In a possible implementation manner, the device further includes:

[0213] The second sending module is used to send coverage data to the second electronic device, wherein the coverage data is used to cover the input data of the target function to be debugged.

[0214] In a possible implementation, a first preset buffer for buffering coverage data is provided in the first electronic device;

[0215] The second sending module is used for:

[0216] The physical address of the first preset buffer is sent to the second electronic device, so that the second electronic device obtains the overwriting data according to the physical address of the first preset buffer.

[0217] In a possible implementation, a second preset buffer for buffering tracking data is provided in the first electronic device, and the apparatus further includes:

[0218] A first writing module, configured to write the trace data of the target debugging function from the second electronic device into the second preset buffer;

[0219] The generating module is used for generating a tracing data file in a preset format according to all tracing data in the second preset buffer in response to the second preset buffer being full, and clearing the second preset buffer.

[0220] In a possible implementation, the target operating system adopts a real-time operating system.

[0221] Figure 6 Another block diagram of the code debugging device provided by the embodiment of the present disclosure is shown. The device is applied to a second electronic device. Figure 6 As shown, the code debugging device includes:

[0222] A second acquisition module 61 is used to acquire, from the first electronic device, a target insertion position of a target debugging function in a code of a target operating system, and a first address of the target debugging function in an executable file, wherein the target operating system represents an operating system running on the second electronic device;

[0223] A third determining module 62, configured to determine a virtual address of the target debugging function in the memory according to the first address;

[0224] The replacement module 63 is used to replace the empty instruction corresponding to the target insertion position in the target function to be debugged with a jump instruction corresponding to the virtual address, wherein the jump instruction is used to jump to the target debugging function.

[0225] In a possible implementation manner, the device further includes:

[0226] A mapping module is used to map the target operating system portion in the executable file to the memory in response to power-on to start the target operating system; wherein, when the target operating system is started, the debug function portion in the executable file remains in a non-mapped state.

[0227] In one possible implementation,

[0228] The third determining module 62 is used for: in response to determining, according to the first address, that the virtual address in the memory has not been allocated for the target debugging function, allocating the virtual address for the target debugging function;

[0229] The device further includes: a copy module, configured to copy the target debugging function from the executable file to the memory according to the first address, and to establish a mapping relationship between the physical address of the target debugging function in the memory and the virtual address.

[0230] In a possible implementation manner, the device further includes:

[0231] A third acquisition module, used to acquire coverage data from the first electronic device;

[0232] The coverage module is used to cover the input data of the target function to be debugged with the coverage data.

[0233] In a possible implementation manner, the third acquisition module is used to:

[0234] Acquire, from the first electronic device, a physical address of a first preset buffer area in the first electronic device for buffering overlay data;

[0235] The coverage data is obtained from the first preset buffer according to the physical address of the first preset buffer.

[0236] In a possible implementation, a third preset buffer for buffering tracking data is provided in the second electronic device, and the apparatus further includes:

[0237] A second writing module, used for writing the tracing data obtained by the target debugging function into the third preset buffer;

[0238] A serial port printing or sending module is used to, in response to the third preset buffer being full, perform serial port printing on all tracking data in the third preset buffer and clear the third preset buffer; or, in response to the third preset buffer being full, send all tracking data in the third preset buffer to the first electronic device and clear the third preset buffer.

[0239] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiments. Its specific implementation and technical effects can refer to the description of the above method embodiments. For the sake of brevity, they will not be repeated here.

[0240] The present disclosure also provides a computer-readable storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the above method is implemented. The computer-readable storage medium may be a non-volatile computer-readable storage medium, or may be a volatile computer-readable storage medium.

[0241] The embodiment of the present disclosure further provides a computer program, including a computer-readable code. When the computer-readable code is executed in an electronic device, a processor in the electronic device executes the above method.

[0242] The embodiments of the present disclosure also provide a computer program product, including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in an electronic device, a processor in the electronic device executes the above method.

[0243] An embodiment of the present disclosure also provides an electronic device, comprising: one or more processors; and a memory for storing executable instructions; wherein the one or more processors are configured to call the executable instructions stored in the memory to execute the above method.

[0244] The electronic device may be provided as a terminal, a server, or a device in other forms.

[0245] Figure 71 is a block diagram of an electronic device 1900 provided in an embodiment of the present disclosure. For example, the electronic device 1900 may be provided as a terminal or a server. Figure 7 , the electronic device 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions executable by the processing component 1922, such as an application. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.

[0246] The electronic device 1900 may also include a power supply component 1926 configured to perform power management of the electronic device 1900, a wired or wireless network interface 1950 configured to connect the electronic device 1900 to a network, and an input / output interface 1958 (I / O interface). The electronic device 1900 may operate based on an operating system stored in the memory 1932, such as a Microsoft Server operating system (Windows Server 2003). TM ), a graphical user interface operating system launched by Apple (MacOS X TM ), a multi-user, multi-process computer operating system (Unix TM ), a free and open source Unix-like operating system (Linux TM ), an open source Unix-like operating system (FreeBSD TM ) or similar.

[0247] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions, which can be executed by the processing component 1922 of the electronic device 1900 to perform the above method.

[0248] The present disclosure may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present disclosure.

[0249] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples of computer-readable storage media (a non-exhaustive list) include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not to be interpreted as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

[0250] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0251] The computer program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be customized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0252] Various aspects of the present disclosure are described herein with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0253] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0254] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0255] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of the module, program segment or instruction includes one or more executable instructions for realizing the specified logical function. In some alternative implementations, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

[0256] The computer program product may be implemented in hardware, software or a combination thereof. In one optional embodiment, the computer program product is embodied as a computer storage medium, and in another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (SDK) and the like.

[0257] The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, they will not be repeated herein.

[0258] If the technical solution of the embodiments of the present disclosure involves personal information, the product using the technical solution of the embodiments of the present disclosure has clearly informed the personal information processing rules and obtained the individual's voluntary consent before processing the personal information. If the technical solution of the embodiments of the present disclosure involves sensitive personal information, the product using the technical solution of the embodiments of the present disclosure has obtained the individual's separate consent before processing the sensitive personal information, and at the same time meets the requirement of "explicit consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set to inform that the personal information collection scope has been entered and personal information will be collected. If the individual voluntarily enters the collection scope, it is deemed that he or she agrees to collect his or her personal information; or on the device for processing personal information, when the personal information processing rules are notified by obvious signs / information, the individual's authorization is obtained through pop-up information or by asking the individual to upload his or her personal information; the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the type of personal information processed.

[0259] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A code debugging method, characterized in that: The method is applied to a first electronic device, and the method includes: Acquire the name of the target to-be-debugged function in the target operating system running on the second electronic device, and the name of the target debugging function; Determine the target insertion position of the target debugging function in the code of the target operating system according to the name of the target to-be-debugged function and the symbol table file; Determine the first address of the target debugging function in the executable file according to the name of the target debugging function and the symbol table file; The target insertion position and the first address are sent to the second electronic device.

2. The method according to claim 1, characterized in that The method further comprises: The source code of the target operating system and the preset debugging function are compiled to generate the executable file and the symbol table file; wherein the function to be debugged of the target operating system includes an inserted null instruction; the function to be debugged includes the target function to be debugged, and the debugging function includes the target debugging function.

3. The method according to claim 2, characterized in that At least one null instruction is inserted before and after the entry of the function body of the function to be debugged of the target operating system.

4. The method according to claim 2, characterized in that: The step of compiling the source code of the target operating system and the preset debugging function to generate the executable file and the symbol table file comprises: The source code of the target operating system and the preset debugging function are compiled as a whole to generate the executable file and the symbol table file.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Sending coverage data to the second electronic device, wherein the coverage data is used to cover input data of the target function to be debugged.

6. The method according to claim 5, characterized in that The first electronic device is provided with a first preset buffer for buffering the coverage data; The sending the coverage data to the second electronic device includes: The physical address of the first preset buffer is sent to the second electronic device, so that the second electronic device obtains the overwriting data according to the physical address of the first preset buffer.

7. The method according to any one of claims 1 to 4, characterized in that The first electronic device is provided with a second preset buffer for buffering tracking data, and further includes: Writing the trace data of the target debugging function from the second electronic device into the second preset buffer; In response to the second preset buffer being full, generating a tracing data file in a preset format according to all tracing data in the second preset buffer, and clearing the second preset buffer.

8. The method according to any one of claims 1 to 4, characterized in that The target operating system adopts a real-time operating system.

9. A code debugging method, characterized in that: The method is applied to a second electronic device, and the method includes: Acquire, from the first electronic device, a target insertion position of a target debugging function in a code of a target operating system, and a first address of the target debugging function in an executable file, wherein the target operating system represents an operating system running on the second electronic device; Determine the virtual address of the target debugging function in the memory according to the first address; The empty instruction corresponding to the target insertion position in the target function to be debugged is replaced with a jump instruction corresponding to the virtual address, wherein the jump instruction is used to jump to the target debugging function.

10. The method according to claim 9, characterized in that The method further comprises: In response to power-on, a portion of the target operating system in the executable file is mapped to a memory to start the target operating system; wherein, when the target operating system is started, a portion of the debugging function in the executable file remains in a non-mapped state.

11. The method according to claim 9, characterized in that Determining the virtual address of the target debug function in the memory according to the first address includes: in response to determining that the virtual address in the memory has not been allocated for the target debug function according to the first address, allocating the virtual address to the target debug function; The method further includes: copying the target debugging function from the executable file to the memory according to the first address, and establishing a mapping relationship between the physical address of the target debugging function in the memory and the virtual address.

12. The method according to any one of claims 9 to 11, characterized in that The method further comprises: Acquire coverage data from the first electronic device; The coverage data is used to cover the input data of the target function to be debugged.

13. The method according to claim 12, characterized in that The acquiring coverage data from the first electronic device includes: Acquire, from the first electronic device, a physical address of a first preset buffer area in the first electronic device for buffering overlay data; The coverage data is obtained from the first preset buffer according to the physical address of the first preset buffer.

14. The method according to any one of claims 9 to 11, characterized in that The second electronic device is provided with a third preset buffer for buffering tracking data, and further includes: Writing the trace data obtained by the target debugging function into the third preset buffer; In response to the third preset buffer being full, all the tracking data in the third preset buffer are serially printed and the third preset buffer is cleared; or, in response to the third preset buffer being full, all the tracking data in the third preset buffer are sent to the first electronic device and the third preset buffer is cleared.

15. A code debugging device, characterized in that: The device is applied to a first electronic device, and includes: A first acquisition module, used to acquire the name of a target to-be-debugged function and the name of a target debugging function in a target operating system running on a second electronic device; A first determining module, used for determining a target insertion position of the target debugging function in the code of the target operating system according to the name of the target function to be debugged and a symbol table file; A second determining module is used to determine a first address of the target debugging function in the executable file according to the name of the target debugging function and the symbol table file; The first sending module is used to send the target insertion position and the first address to the second electronic device.

16. A code debugging device, characterized in that: The device is applied to a second electronic device, and includes: A second acquisition module is used to acquire, from the first electronic device, a target insertion position of a target debugging function in a code of a target operating system, and a first address of the target debugging function in an executable file, wherein the target operating system represents an operating system running on the second electronic device; A third determining module, configured to determine a virtual address of the target debugging function in the memory according to the first address; The replacement module is used to replace the empty instruction corresponding to the target insertion position in the target function to be debugged with a jump instruction corresponding to the virtual address, wherein the jump instruction is used to jump to the target debugging function.

17. An electronic device, characterized in that: include: one or more processors; a memory for storing executable instructions; The one or more processors are configured to call the executable instructions stored in the memory to execute the method according to any one of claims 1 to 14.

18. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 14 is implemented.

19. A computer program product comprising computer readable code, or a non-volatile computer readable storage medium carrying computer readable code, characterized in that: When the computer readable code is executed in an electronic device, a processor in the electronic device executes the method according to any one of claims 1 to 14.

Images