Function call chain determination method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a function call chain determination method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring to-be-analyzed tracking data generated in a program running process; based on a memory dump file related to the program, determining an assembly instruction corresponding to each piece of to-be-analyzed tracking data; classifying the to-be-analyzed tracking data according to threads to obtain the tracking data of each thread; and for each thread, performing function call relationship analysis based on the assembly instruction of the tracking data of the corresponding thread to obtain a function call chain of the corresponding thread. By adopting the method, the accuracy of determining the function call chain can be improved.

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for determining a function call chain. Background Art

[0002] During software development, trace and debug are common problem-solving methods. The most intuitive way to present tracing is through the function call chain, which allows you to visually see whether function execution meets expectations, and then analyze and locate problems.

[0003] The traditional way to determine the function call chain is usually to use a Profiler (performance analyzer) tool, such as perf (Performance Analysis Tool). The principle of the Profiler tool to obtain the function call chain is to collect and analyze the stack information of the function call when the program is running to generate the function call chain. Specifically, when the program is executed, each time a function is called, the function's return address, parameters, local variables and other information will be stored in the stack. The Profiler tool usually injects code into the program through the instrumentation technology so that the stack information of the function call can be captured, and then analyzed to construct the function call chain. At the same time, in order to reduce the impact on program performance, the Profiler tool usually adopts a sampling-based method for stack collection, that is, by setting the sampling rate, only a part of the stack is collected within a certain time interval, thereby reducing the impact on the program's runtime performance.

[0004] Since perf usually samples stack information within a certain time interval, if the execution time of a function is less than the sampling interval, the call information of the function will not be collected, which will result in inaccurate function call chain. Summary of the Invention

[0005] Based on this, it is necessary to provide a method, device, computer equipment, computer-readable storage medium and computer program product for determining a function call chain that can improve the accuracy of function call chain construction in response to the above technical problems.

[0006] In a first aspect, the present application provides a method for determining a function call chain, comprising:

[0007] Obtain the tracking data to be analyzed during the program running;

[0008] Determining, based on a memory dump file associated with the program, an assembly instruction corresponding to each trace data to be analyzed;

[0009] Classifying the tracing data to be analyzed by thread to obtain tracing data of each thread;

[0010] For each thread, a function call relationship analysis is performed based on the assembly instructions of the corresponding thread's tracking data to obtain the function call chain of the corresponding thread.

[0011] In a second aspect, the present application further provides a device for determining a function call chain, comprising:

[0012] The acquisition module is used to obtain the tracking data to be analyzed during the program running process;

[0013] a determination module, configured to determine, based on a memory dump file associated with the program, an assembly instruction corresponding to each piece of trace data to be analyzed;

[0014] A classification module, configured to classify the trace data to be analyzed by thread to obtain trace data of each thread;

[0015] A building module is used to perform function call relationship analysis on each thread based on the assembly instructions of the tracking data of the corresponding thread to obtain the function call chain of the corresponding thread.

[0016] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above-mentioned method for determining a function call chain when executing the computer program.

[0017] In a fourth aspect, the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method for determining the function call chain are implemented.

[0018] In a fifth aspect, the present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the above-mentioned method for determining a function call chain.

[0019] The above-mentioned method, device, computer equipment, computer-readable storage medium and computer program product for determining the function call chain obtain the tracking data to be analyzed during the program execution, and then determine the assembly instructions corresponding to each tracking data to be analyzed based on the memory dump file related to the program. When constructing the function call chain by thread, the actual jump relationship between each tracking data can be analyzed based on the assembly instructions, so that the function call chain during the program execution can be accurately constructed. The present application analyzes the tracking data recorded during the program execution. On the one hand, it will not interrupt the program execution and therefore will not affect the performance. On the other hand, it can avoid the omission of some data due to data sampling operations, so that a complete function call chain can be constructed, thereby improving the accuracy of the function call chain construction. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 FIG. 1 is an application environment diagram of a method for determining a function call chain in one embodiment;

[0022] Figure 2 1 is a flow chart of a method for determining a function call chain in one embodiment;

[0023] Figure 3 A flowchart illustrating steps for obtaining tracking data to be analyzed in one embodiment;

[0024] Figure 4 A flowchart illustrating steps for determining assembly instructions for trace data in one embodiment;

[0025] Figure 5 A flowchart illustrating steps for classifying tracking data in one embodiment;

[0026] Figure 6 A schematic diagram of a flow chart of steps for constructing a function call relationship tree in one embodiment;

[0027] Figure 7 A schematic diagram of function calls and function returns during the process of building a function call chain in one embodiment;

[0028] Figure 8 A schematic flow chart of a step of merging function call subtrees in one embodiment;

[0029] Figure 9 An example of two function call subtrees in one embodiment;

[0030] Figure 10 is a structural block diagram of a device for determining a function call chain in one embodiment;

[0031] Figure 11 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0033] During software development, trace and debug are common problem-solving methods. The most intuitive way to present a trace is as a function call chain, which allows you to visually see whether function execution meets expectations and thus analyze and locate the problem.

[0034] Traditional methods for determining function call chains can be divided into three main categories: sampling-based dynamic tracing, code instrumentation, and static analysis methods. These methods differ significantly in accuracy, performance loss, and deployment costs.

[0035] Sampling-based dynamic tracing (such as Linux perf) periodically interrupts program execution to capture call stack information. However, its sampling mechanism can cause short-lived functions to be missed. Furthermore, such tools rely on kernel module support (such as the perf_event module), which can affect system real-time performance due to resource contention in high-performance-sensitive scenarios. Despite their low deployment costs, sampling accuracy and runtime interference limit their application in embedded real-time systems.

[0036] Code instrumentation solutions (such as GNU gprof) collect comprehensive data by inserting monitoring code during compilation or runtime, enabling accurate function call relationships. However, the additional instructions introduced by instrumentation can degrade program performance and require recompilation of the target code, making them difficult to use in production environments. Furthermore, improperly selected instrumentation points can disrupt existing control flow logic, increasing debugging complexity.

[0037] Static analysis methods (such as parsing tools based on Clang ASTMatcher) construct call graphs by analyzing source code or intermediate representations, avoiding runtime overhead. However, these methods rely on static deduction of program semantics, making them difficult to handle scenarios such as dynamically loaded libraries and polymorphic calls, and they also suffer from path explosion.

[0038] This application proposes a pure software non-intrusive solution based on a tracing component (such as the Coresight Trace component), which captures the entire call chain by parsing the ETM (Embedded Trace Macrocell) instruction stream log; the tracing component is a hardware circuit independent of the processor, so it will not affect the program's execution on the processor when collecting tracing data. This method is applicable to operating systems running on ARM architecture hardware (such as the Linux operating system or the QNX (an embedded system) operating system, etc.). Among them, Coresight is a debugging and tracing architecture. By enabling the Coresight Trace component, it can record the instructions executed on the processor (such as the CPU, Central Processing Unit) core, so the function call chain calculated by Coresight Trace will not have inaccurate data; and the Coresight component is a hardware circuit independent of the CPU (Central Processing Unit, Central Processing Unit), so it will not affect the performance of the original program when collecting tracing data. Similarly, when using it, it does not need to rely on the kernel to enable certain configurations that affect performance.

[0039] In summary, compared with the above-mentioned traditional methods, the present application can directly utilize the standardized log format of the Coresight architecture and calculate the function call chain without the need for additional hardware equipment (such as a physical debugging interface, etc.), which can greatly reduce the implementation cost. On the other hand, the present application adopts instruction stream bypass parsing technology (i.e., capturing trace data through the Coresight component), which has lower performance loss than the perf sampling solution. Function calls as short as a single cycle can also be captured without affecting system performance. On the other hand, the present application solution obtains assembly instructions through disassembly and then processes them. It can support binary files with symbol stripping in the production environment, solves the recompilation dependency problem of traditional instrumentation solutions, and is more flexible in deployment. Experiments show that this solution can significantly shorten the fault location time in program fault diagnosis, such as the diagnosis of occasional crashes in smart car systems, while avoiding the impact on system startup speed.

[0040] The following is a detailed introduction to the solution of this application. Before the introduction, some of the terms involved are explained:

[0041] ARM: ARM (Advanced RISC Machines) is a computer processor architecture and instruction set developed by ARM Holdings. The ARM architecture is designed to be streamlined and efficient, and is widely used in mobile devices, embedded systems, and consumer electronics.

[0042] Coresight: Coresight is a debugging and tracing technology developed by ARM that provides highly integrated hardware debugging and performance analysis capabilities. It can be understood as a collection of debugging and tracing components within the ARM architecture, including debug ports, trace components, and debug logic. Designed for use in ARM architecture processor systems, it provides software developers and system engineers with more powerful debugging and analysis tools.

[0043] Exception: ARM Exception refers to the exception handling mechanism in ARM processors. When the processor encounters an exception (such as an invalid instruction, memory access error, interrupt request, etc.), the exception handler is triggered to handle these exceptions.

[0044] ELF: ELF stands for Executable and Linkable Format. It is a common binary file format used to represent executable files, shared libraries, and object files in Unix-like systems. The ELF format defines how these binary files are organized and laid out, and provides information such as executable instructions, data segments, symbol tables, and dynamic linking information.

[0045] OpenCSD: Open CoreSight Debug (OpenCSD) is an open source debugging tool for processing and parsing data from the ARM CoreSight debugger.

[0046] Process: A process is an operating system's abstraction of a running program. Each process has its own independent memory space, execution control flow, and system resources, such as files and devices.

[0047] Thread: A thread is part of a process and is an execution path that runs within the process. Threads share the same process's memory space and system resources. Multiple threads within the same process can execute simultaneously and access the same data and context. Threads also share the process's state information, such as open files and signal handling. Switching between threads is faster than switching between processes because only the thread's execution context needs to be switched.

[0048] Task Scheduling: Task scheduling is the process by which the operating system manages and arranges the execution order of processes and jobs. The task scheduler is responsible for selecting appropriate processes or jobs and allocating system resources (such as CPU time and memory) to them based on a specific scheduling algorithm, thereby achieving efficient utilization of system resources and improving system performance.

[0049] Context: In computer science, "context" generally refers to the environment and state information required by a program or process during execution. It includes the various data and resources required for the program to run, as well as related information used to manage and control program execution.

[0050] The following is a detailed description of this application:

[0051] The method for determining the function call chain provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown. Among them, the computer device 102 communicates with the electronic device 104 through the network. A program is running on the electronic device 104, and the program can generate an operation record during operation, and the operation record may include tracking data. The tracking data can be stored locally on the electronic device 104, or stored on a data storage system through the electronic device 104. The data storage system can be integrated on the electronic device 104, or can be placed on the cloud or other network servers. The computer device 102 can obtain the tracking data to be analyzed from the electronic device 104 or the data storage system, and then determine the assembly instructions corresponding to each tracking data to be analyzed based on the memory dump file related to the program; classify the tracking data to be analyzed by thread to obtain the tracking data of each thread; for each thread, perform function call relationship analysis based on the assembly instructions of the tracking data of the corresponding thread to obtain the function call chain of the corresponding thread. It can be understood that in some embodiments, the electronic device 104 can also execute the method for determining the function call chain locally, and the embodiments of the present application are not limited to this.

[0052] The computer device 102 and / or the electronic device 104 may be a terminal or a server. The terminal may be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices may be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. The head-mounted devices may be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services.

[0053] In an exemplary embodiment, Figure 2 As shown, a method for determining a function call chain is provided, and the method is applied to Figure 1 The computer device 102 in FIG. 1 is used as an example to illustrate (it can be understood that this method can also be applied to Figure 1Specifically, the method includes the following steps 202 to 206.

[0054] Step 202: Acquire the tracking data to be analyzed generated during the program execution.

[0055] It should be noted that the solution of this application is based on a tracking component method, that is, a tracking component is pre-deployed in the electronic device running the program to record the tracking data generated during the program running. The tracking component can be, for example, the Coresight Trace component.

[0056] In some embodiments, the Coresight Trace component can record the execution records of jump instructions during program execution. The recorded data can be called trace data. For example, the trace data may include address information, the processor (such as the CPU) where the jump is located, and the jump type of the jump (such as whether it is a sequential jump or an abnormal jump, etc., and an abnormal jump may be caused by an abnormal situation such as an invalid instruction, a memory access error, an interrupt request, etc.). The address information may specifically include the start address (start_addr) (that is, the destination address after the last jump) and the end address (end_addr) (that is, the address where the jump occurs this time).

[0057] In some embodiments, the tracking data is recorded in sequence according to the time sequence in which it is generated, and is also read in sequence according to the time sequence in which it is recorded during subsequent use.

[0058] In some embodiments, the electronic device may capture the tracking data through the tracking component and store it, and the computer device may obtain the tracking data to be analyzed from the stored data through any communication method.

[0059] In some embodiments, the computing device may use all trace data captured by the Coresight Trace component on the processor core as the trace data to be analyzed. In other embodiments, the computing device may use a portion of the full trace data as the trace data to be analyzed. For example, the computing device may use trace data related to a specific process as the trace data to be analyzed.

[0060] Step 204 : determining the assembly instructions corresponding to each trace data to be analyzed based on the memory dump file related to the program.

[0061] A memory dump file, also known as a dump file, is a snapshot file of the system or program state at a specific moment in an electronic device. It can be understood as a memory image of a process and includes multiple ELF files. Assembly instructions are instructions used in assembly language and are operational commands that a computer can recognize and execute. Assembly instructions can include, for example, data transfer instructions, arithmetic operation instructions, logical operation instructions, control flow instructions, and system transaction instructions.

[0062] Specifically, when a function call chain needs to be constructed, the computer device can obtain and save a dump file of the executable code segment in the memory of the electronic device. The dump file can reflect the actual execution status of the program. In some embodiments, based on actual conditions, when a function call chain needs to be constructed for a specified process, the computer device can obtain and save a dump file related to the specified process in the memory of the electronic device. When a function call chain needs to be constructed for multiple processes, the computer device can obtain and save the dump files corresponding to each of the multiple processes.

[0063] Furthermore, for each piece of tracing data to be analyzed, the computer device may determine an ELF file corresponding to the tracing data from the Dump file, and then perform disassembly based on the ELF file to obtain assembly instructions for the tracing data.

[0064] In some embodiments, if the ELF file includes symbol information, it can be further parsed to obtain the function symbols (i.e., function names) corresponding to each tracing data; if the ELF file includes debugging information, it can be further parsed to obtain the function symbols corresponding to each tracing data, as well as the source code file path and code line number.

[0065] Step 206 : Classify the trace data to be analyzed by thread to obtain the trace data of each thread.

[0066] In some embodiments, during program execution, the tracing component may record the identifier of the process and / or thread to which the instruction belongs, and when a process and / or thread switch occurs, the tracing component updates it. For example, the tracing component may record the identifier of the process and / or thread in a register, and when a process and / or thread switch occurs, the value in the register is updated. Therefore, in this case, the identifier of the thread to which the corresponding instruction belongs may be recorded in the tracing data. In this way, the computer device can classify each tracing data by the thread identifier in the tracing data, and obtain the tracing data included in each thread.

[0067] In some embodiments, in some cases, due to the lack of kernel configuration, valid thread identifiers may not be recorded in the tracing data. In this case, the computer device can determine whether different tracing data belong to the same thread through the address information of the tracing data, so as to classify the tracing data belonging to the same thread into the same category, and classify the tracing data that do not belong to the same thread into different categories.

[0068] Step 208 : For each thread, a function call relationship analysis is performed based on the assembly instructions of the tracing data of the corresponding thread to obtain a function call chain of the corresponding thread.

[0069] Specifically, after classifying the tracing data by thread, a corresponding function call chain can be constructed for each thread sequentially or in parallel. It is understood that function calls usually occur within a thread. In this application, after classifying the tracing data by thread, a corresponding function call chain is constructed for each thread. This can improve both the accuracy and efficiency of constructing the function call chain.

[0070] In some special cases, such as when different threads execute the same function in parallel, failure to categorize the trace data by thread can lead to incorrect determination of function call relationships, which in turn can cause errors in function call chain construction. This application avoids these special cases and improves the accuracy of function call chain construction.

[0071] When constructing a function call chain for any thread, the computer device can sequentially determine whether a call relationship exists between the functions corresponding to each trace data item based on the assembly instructions of the thread's trace data. If so, the corresponding function call relationship is constructed. Once all trace data for the thread has been analyzed, the function call chain for the thread is obtained.

[0072] In some embodiments, the function call relationship can be stored in a tree structure, so the function call relationship tree finally obtained can represent the function call chain.

[0073] The above-mentioned method for determining the function call chain obtains the tracking data to be analyzed during the program execution, and then determines the assembly instructions corresponding to each tracking data to be analyzed based on the memory dump file related to the program. Then, when constructing the function call chain by thread, the actual jump relationship between each tracking data can be analyzed based on the assembly instructions, so that the function call chain during the program execution can be accurately constructed. This application analyzes the recorded data during the program execution. On the one hand, it will not interrupt the program execution and therefore will not affect the performance. On the other hand, it can avoid the omission of some data due to data sampling operations, so that a complete function call chain can be constructed, thereby improving the accuracy of the function call chain construction.

[0074] In some embodiments, the method for determining the function call chain may include the following steps: obtaining the tracing data to be analyzed generated during the execution of the program; determining the assembly instructions and function symbols corresponding to each tracing data to be analyzed based on a memory dump file related to the program; classifying the tracing data to be analyzed by thread to obtain the tracing data of each thread; for each thread, performing function call relationship analysis based on the assembly instructions of the tracing data of the corresponding thread, and constructing the function call chain of the corresponding thread based on the analysis results and in combination with the function symbols; the function call chain shows the call relationship between functions indicated by different function symbols.

[0075] Among them, for each thread, function call relationship analysis is performed based on the assembly instructions of the tracing data of the corresponding thread, and the function call chain of the corresponding thread is constructed based on the analysis results and combined with the function symbols, which may include: for each thread, function call relationship analysis is performed based on the assembly instructions of the tracing data of the corresponding thread, and a function call relationship tree is constructed based on the analysis results. In the process of constructing the function call relationship tree, for each node, the function symbol corresponding to the tracing data related to the node is stored in the node; the function call relationship tree finally constructed represents the function call relationship chain.

[0076] Next, we will explain each step in the method of determining the function call chain in more detail:

[0077] In some embodiments, a computer device may use the tracing data related to a specified process as the tracing data to be analyzed, so obtaining the tracing data to be analyzed generated during the program execution includes: searching for mapping information based on the process identifier of the specified process to determine the specified virtual address of the specified process based on the found mapping information; and obtaining the tracing data to be analyzed related to the specified process generated during the program execution based on the process identifier and the specified virtual address.

[0078] In actual applications, electronic devices can assign a process identifier (PID) to each process when a program is running. When analyzing program execution, an analyst or user can determine the PID of a specific process from the PIDs of each process. Based on the PID of the specific process, mapping information (also known as map information) associated with the specific process is determined and saved. The map information records the virtual address of the specific process (also known as the specified virtual address).

[0079] For example, the electronic device can use the process pid to find the process in / proc / <pid>The maps file is found in the / directory. This important file provides information about the memory map of the current process. By examining the maps file, you can obtain detailed information about the process's memory map, including libraries loaded by the program, the address ranges of the heap and stack, and other memory areas used by the process. Electronic devices can transfer maps files to computers for subsequent processing.

[0080] Furthermore, the computer device may obtain the tracking data to be analyzed related to the designated process generated during the program execution based on the process identifier and the designated virtual address of the designated process.

[0081] In some embodiments, a tracing component can be pre-configured using the process ID and virtual address of the specified process (e.g., by configuring a Coresight register to enable Coresight Trace), so that when the program is running, the tracing component can automatically record and save tracing data related to the specified process. The computer device can then obtain the tracing data as tracing data to be analyzed.

[0082] In other embodiments, when the program is running, the tracking component can automatically record the full amount of tracking data. After receiving the process identifier and the specified virtual address specified by the computer device, the full amount of tracking data is filtered to obtain the tracking data related to the specified process as the tracking data to be analyzed, and then the tracking data to be analyzed is transmitted to the computer device for subsequent processing.

[0083] In other embodiments, when the program is running, the tracking component can automatically record and save the full amount of tracking data. After the computer device obtains the full amount of tracking data, the host computer or computer device can filter the full amount of tracking data based on the process identifier and the specified virtual address of the specified process to obtain the tracking data related to the specified process as the tracking data to be analyzed.

[0084] It should be noted that when the tracing component records tracing data (whether it is full tracing data or tracing data for a specific process), the tracing component can compress the tracing data in a specific manner and save it to a specific memory address via DMA (Direct Memory Access). The computer device can then periodically save the tracing data in memory. In some embodiments, to save storage space, the saved tracing data can be highly compressed binary data, and the original tracing data can be decoded and used using debugging tools (such as OpenCSD).

[0085] In some embodiments, the program in the present application may be a program running under an architecture such as the ARM CoreSight SoC-400. Considering that multi-core heterogeneous SoC (System on a Chip) is an increasingly common architecture, and the codes running on different cores in such an SoC are at different functional safety levels, the present application can obtain configuration information (such as process ID, specified virtual address, etc.) through the A core of the electronic device with a low functional safety level, and use the inter-core communication technology IPC (Inter-Process Communication) to allow the R core with a higher functional safety level to configure Coresight. This design enables the same method to capture trace data on all processor cores (A core, R core, DSP (Digital Signal Processor), NPU (Neural Processing Unit), etc.) in a multi-core heterogeneous architecture.

[0086] For a specific example, see Figure 3 The process of obtaining the tracing data to be analyzed is as follows: determine and save the map information based on the process ID; configure the tracing component based on the process ID and the specified virtual address in the map information; capture the original tracing data through the tracing component; and decode the original tracing data through a debugging tool (such as OpenCSD) to obtain the tracing data to be analyzed.

[0087] In the above embodiment, the tracing data related to the specified process captured by the tracing component can be obtained through configuration, and the tracing data related to the specified process is used as the tracing data to be analyzed, thereby realizing the construction of the function call chain for the specified process.

[0088] In some embodiments, based on a memory dump file associated with a program, determining the assembly instructions corresponding to each piece of tracing data to be analyzed includes: determining the ELF files corresponding to each piece of tracing data from the memory dump file associated with the program; determining the offset addresses of each piece of tracing data to be analyzed in the corresponding ELF files; and performing disassembly based on the ELF files corresponding to each piece of tracing data to be analyzed and the offset addresses in the corresponding ELF files to obtain the assembly instructions corresponding to each piece of tracing data to be analyzed.

[0089] As previously mentioned, the trace data to be analyzed includes address information, namely, start_addr and end_addr. These two addresses are virtual addresses, with end_addr indicating where a jump occurred. The computer device can obtain map information related to the program, more specifically, map information related to a specific process within the program. This map information records the virtual address range corresponding to each ELF file.

[0090] In this way, the computer device can compare the end address (end_addr) in the trace data with the virtual address range corresponding to each ELF file to find which ELF file's virtual address range the end address (end_addr) of the trace data falls within. The ELF file corresponding to the virtual address range in which the end address (end_addr) falls is the ELF file corresponding to the trace data.

[0091] Then, the computer device can subtract the base address of the ELF file from the end address (end_addr) to obtain the offset address, which is the address of the instruction corresponding to the trace data in the ELF file. Therefore, the assembly instruction corresponding to the trace data can be disassembled based on the offset address and the ELF file.

[0092] In some embodiments, the method further includes: if the ELF file includes symbol information, parsing the symbol information to obtain the function symbols corresponding to each tracing data, and / or, if the ELF file includes debugging information, parsing the debugging information to obtain the function symbols corresponding to each tracing data, as well as the source code file path and code line number.

[0093] In some cases, the ELF file also includes symbol information and / or debugging information. If this information exists, it can be further parsed to obtain function symbols, or function symbols, as well as source code file paths and code line numbers. Among them, the function symbol specifically refers to the function name, which is easy to understand the specific function corresponding to the tracking data; the source code file path and code line number refer to the source code file path and code line number where the instruction corresponding to the tracking data is located, which can help debuggers quickly locate the source code when a system crash or failure occurs. The function symbols and / or source code file paths and code line numbers for different tracking data can be stored in the nodes of the constructed function call relationship tree, which facilitates the storage of more information in the function call relationship tree, making the presentation of the function call chain more readable.

[0094] In some embodiments, if the ELF file does not include symbol information and / or debugging information, and the symbol information and / or debugging information is stored in another file, the computer device may find the symbol information and / or debugging information of each trace data from the other file based on the mapping relationship between the data of the two files, and then parse the symbol information and / or debugging information.

[0095] For a specific example, see Figure 4 , which shows the specific process of determining the assembly instructions of tracing data in one embodiment: obtaining an unprocessed piece of tracing data from multiple pieces of tracing data; determining the ELF file corresponding to the tracing data; disassembling based on the ELF file to obtain the assembly instructions of the tracing data; if the ELF file contains symbol information and / or debugging information, parsing it; determining whether all the tracing data have been processed, if so, ending the process; if not, obtaining the next piece of tracing data and continuing processing.

[0096] In the above embodiment, a memory dump file generated by program execution is obtained, and for each trace data, it is first determined which ELF file in the memory dump file the trace data corresponds to, and then the offset address of the trace data in the ELF file is determined based on the address information in the trace data. In this way, the trace data is located in the ELF file, and then disassembly can be performed based on the ELF file corresponding to the trace data and the offset address in the corresponding ELF file to accurately obtain the assembly instructions corresponding to the trace data.

[0097] When constructing a function call chain using assembly instructions, the tracing data can be first classified by thread, and then the function call chain can be constructed for each thread. The specific process of classifying the tracing data is as follows:

[0098] In some embodiments, the tracing data to be analyzed is classified by thread to obtain the tracing data of each thread, including: obtaining the current tracing data to be classified from multiple tracing data to be analyzed; determining whether the tracing data to be classified belongs to any thread in the current thread list, and if so, classifying the tracing data to be classified to the thread; if not, classifying the tracing data to be classified to a new thread; returning to obtain the current tracing data to be classified from the multiple tracing data to be analyzed and continuing execution until the classification of all tracing data to be analyzed is completed.

[0099] Specifically, the computer device may sequentially read a piece of tracking data to be analyzed as the current tracking data to be classified according to the time sequence of the tracking data, and then determine whether the tracking data to be classified belongs to any thread in the current thread list. If so, the tracking data to be classified is classified into the thread; if not, a new thread is added to the thread list and the tracking data to be classified is classified into the new thread. Then, the next tracking data is read as the new tracking data to be classified and classified in the same manner until all tracking data are classified.

[0100] In some embodiments, the computer device may classify the first trace data read into the first thread, and then classify subsequent trace data in the above manner, and the threads in the thread list are also updated as the classification process proceeds.

[0101] In some embodiments, for each classification, the computer device may traverse each thread in the current thread list, and for the currently traversed thread, compare the last tracing data of the thread with the tracing data to be classified to determine whether the two tracing data belong to the same thread. If so, it is determined that the tracing data to be classified belongs to the thread; if not, the tracing data to be classified is continued to be traversed to the next thread until the classification of the tracing data to be classified is achieved or the current thread list is traversed.

[0102] In some embodiments, the computer device may compare the last trace data of the thread with the trace data to be classified based on a determination rule to determine whether the two trace data belong to the same thread. The determination rule defines the conditions under which two trace data belong to or do not belong to the same thread. In some embodiments, there is only one determination rule; in other embodiments, there are multiple determination rules, which may or may not have a priority order.

[0103] In a specific embodiment, reference Figure 5 , which shows the classification process of tracking data in one embodiment:

[0104] Step 502: Read in a piece of tracking data as the second tracking data.

[0105] Step 504: Determine whether a thread list exists. If not, jump to step 516; if so, go to step 506.

[0106] Step 506: Get a thread from the thread list.

[0107] Step 508: Obtain the last piece of tracing data in the thread as the first tracing data.

[0108] Step 510 : Determine whether the first tracing data and the second tracing data belong to the same thread. If so, proceed to step 512 ; if not, proceed to step 514 .

[0109] Step 512: Update the thread's tracking data.

[0110] Step 514: Determine whether the thread list traversal is complete. If the thread list traversal is complete, proceed to step 516; if the thread list traversal is not complete, return to step 506.

[0111] Step 516: Add a new thread to the thread list, and classify the second tracking data into the new thread.

[0112] Step 518: Determine whether all tracking data have been classified. If so, end the process. If not, return to step 502 to continue execution.

[0113] In the above embodiment, the tracing data is classified one by one to classify the tracing data belonging to the same thread into the same class and the tracing data belonging to different threads into different classes, so as to facilitate the subsequent construction of a function call chain for the tracing data of the same class.

[0114] In some embodiments, when there are multiple determination rules with different priority orders, the computer device may determine the thread to which the trace data belongs by:

[0115] In some embodiments, determining whether the tracing data to be classified belongs to any thread in the current thread list includes: determining the determination rule used in the current determination according to the priority order of multiple determination rules; based on the determined determination rule, comparing the tracing data to be classified with the last tracing data of each thread in the current thread list to determine whether the tracing data to be classified belongs to any thread in the current thread list; if the thread to which the tracing data to be classified belongs is found in the current determination, then stop; otherwise, return to the step of determining the determination rule used in the current determination according to the priority order of multiple determination rules and continue to execute to make another determination based on another determination rule.

[0116] Specifically, the computer device may compare the tracking data to be classified with the last tracking data of each thread in the current thread list based on the priority order of multiple judgment rules, starting from the judgment rule with the highest priority, to determine whether the tracking data to be classified belongs to any thread in the current thread list. If the comparison result can determine the thread to which the tracking data to be classified belongs, the judgment is stopped; otherwise, the judgment rule of the next priority is obtained and the judgment is performed again; the execution is repeated in this way until the thread to which the tracking data to be classified belongs is found. If all judgment rules have been executed but the thread to which the tracking data to be classified belongs has not been determined, the tracking data to be classified is classified into a new thread.

[0117] For any judgment rule, when comparing the tracking data to be classified with the last tracking data of each thread in the current thread list based on the judgment rule, each thread in the current thread list can be traversed, and for the currently traversed thread, the last tracking data of the thread can be compared with the tracking data to be classified. If it is found based on the comparison result that the two tracking data do not belong to the same thread, the next thread will be traversed until the thread to which the tracking data to be classified belongs is found. Alternatively, the computer device can also form data groups with the tracking data to be classified and the last tracking data of each thread, and perform judgments on the two tracking data in each group synchronously and in parallel based on the judgment rule, which can improve the judgment efficiency. It should be noted that the above-mentioned parallel or serial judgment methods can be applicable, and the embodiments of the present application do not limit this.

[0118] In the above embodiment, by performing determination in sequence through a plurality of determination rules having a priority order, misclassification can be avoided to the greatest extent, thereby greatly improving the classification accuracy of the tracking data.

[0119] In some embodiments, for ease of description, the last trace data of a thread is taken as the first trace data, and the trace data to be classified is taken as the second trace data. The multiple determination rules include the following rules: a first determination rule: if the first trace data does not undergo an abnormal jump, the first trace data and the second trace data correspond to the same processor core, and the first trace data and the second trace data are sequentially continuous, then the second trace data is determined to belong to the thread to which the first trace data belongs; a second determination rule: if the first trace data undergoes an abnormal jump, the first trace data and the second trace data correspond to the same processor core, and there is an address match between the first trace data and the second trace data, then the second trace data is determined to belong to the thread to which the first trace data belongs; a third determination rule: if the first trace data undergoes an abnormal jump, the first trace data and the second trace data correspond to different processor cores, and there is an address match between the first trace data and the second trace data, then the second trace data is determined to belong to the thread to which the first trace data belongs; wherein the priority of the first determination rule is greater than the priority of the second determination rule, and the priority of the second determination rule is greater than the priority of the third determination rule.

[0120] Specifically, a computer device can read two pieces of tracing data. If the first tracing data does not jump abnormally and the two pieces of tracing data are two consecutive pieces of tracing data on the same CPU core, it indicates that no thread switch has occurred between the two pieces of tracing data, that is, the two pieces of tracing data belong to the same thread. If the first tracing data jumps abnormally, a thread switch may have occurred between the two pieces of tracing data. When a thread switch may have occurred between the two pieces of tracing data, the following determination can be made:

[0121] When two trace data belong to the same CPU core, if the exception return address of the first trace data (where an exception jump occurs) is equal to the starting address start_addr of the second trace data, then it is determined that the first trace data and the second trace data have an address match. This means that an exception (possibly an interrupt, exception, system call, etc.) occurred while the thread was executing on the same CPU. After executing the exception handling function, the thread returned to the location where the exception occurred and continued execution. Therefore, the two trace data belong to the same thread.

[0122] When two trace data do not belong to the same CPU core, if the exception return address of the first trace data (where an exception jump occurs) (where the end address end_addr of the trace data of the exception jump is the exception return address) is equal to the starting address start_addr of the second trace data, then it is determined that there is an address match between the first trace data and the second trace data. This situation means that an exception (which may be an interrupt, exception, system call, etc.) occurred while the thread was executing on the first CPU. After executing the exception handling function, the instruction of the return address continued to be executed on the second CPU. Therefore, the two trace data belong to the same thread.

[0123] Regarding the above judgment rules, it's also important to note that in operating systems like Linux and QNX, when the scheduler performs a thread switch, it must save the original thread's execution context and restore the new thread's execution context. This process is performed by the kernel. This process must occur at a high-priority CPU privilege level, while normal processes run at a low-priority privilege level. Therefore, we can conclude that when a user-mode thread is switched, a user-mode -> kernel-mode -> user-mode switch must occur on the CPU where the thread is executed. Common transitions from user mode to kernel mode include interrupts, exceptions, and system calls. These are all captured by the tracing component and, after decoding, are marked as exception jumps. The corresponding trace data has the jump type of exception jump. Trace data marked as exception jumps has a characteristic: the start_addr value is 0, and the end_addr value is the exception return address. Therefore, we can conclude that when a thread switch occurs on a CPU, an exception must have occurred, which is detected by the tracing component and marked as an exception jump. Based on this, we can know that if a certain trace data is not generated by an abnormal jump, then the subsequent trace data will most likely belong to the same thread as it. That is, corresponding to the first judgment rule mentioned above, it has the highest priority. If a certain trace data is generated by an abnormal jump, then it can be determined whether it and the subsequent trace data correspond to the same CPU and whether there is an address match (that is, whether the abnormal return address of the first trace data is equal to the starting address of the second trace data). In this way, by constantly comparing whether the two trace data belong to the same thread, the trace data can be classified by thread.

[0124] In some embodiments, for the three aforementioned determination rules, the computer device may traverse the thread list three times when making a determination, corresponding to the first determination rule, the second determination rule, and the third determination rule, in sequence. This three-way traversal is performed because the three determination rules have different priorities. The computer device must first ensure that all threads do not match the first determination rule before matching the second determination rule. Similarly, if all threads do not match the second determination rule, the computer device will then match the third determination rule. If the tracking data to be classified cannot be classified after three traversals, it indicates that the tracking data belongs to a new thread and the thread list needs to be updated.

[0125] It is understandable that in other implementation scenarios, there may be more or fewer matching rules, or the priority order of the matching rules may not be set, etc., and the embodiments of the present application are not limited to this.

[0126] In the above embodiment, accurate classification of the tracking data can be achieved through three matching rules with different priority orders.

[0127] The following is a detailed description of the process of constructing a function call chain. Before that, let's first introduce several assembly instructions related to function calls and function returns. For example, in the ARM assembly instruction set, these assembly instructions are the BL instruction, the BLR instruction, and the RET instruction.

[0128] The BL instruction instructs to jump to the destination address and save the function return address (the address of the next instruction) to a register (such as register X30), which can be used for static function calls, and the destination address is known at compile time. For example, the BL instruction can jump the program to a specified address (that is, the destination address) and set register X30 to the function return address before executing the jump. The function return address can specifically be the sum of the end address of the current jump and the instruction length, such as the value of PC+4. Among them, PC points to the end address end_addr of the current jump, and 4 refers to the instruction length; it can be understood that the instruction length can also be other values, and the embodiments of the present application do not limit this. At the same time, the instruction also provides a prompt indicating that this is a subroutine call. In other words, when the program executes the BL instruction, it will transfer the program control to another place, but before executing the jump, it will first store the value of the current position PC+4 in register X30. This register is usually used to save the function return address. Therefore, it can be understood that this instruction implements a call to a subroutine and saves the function return address before the call so that the program can return to the original location and continue to execute after the subroutine is completed.

[0129] The BLR instruction instructs to jump to the destination address stored in the register and save the function return address to a register (such as the X30 register). It can be used for dynamic function calls, and the destination address is determined at runtime. This instruction is a "branch" instruction, which means that it allows the program to jump to another address (that is, the destination address) during execution. Before the jump, the program will store the address of the next instruction that is currently being executed (that is, the function return address) in a specific register X30 so that it can return to the original location and continue execution after the jump. More specifically, this branch instruction is executed by allowing the program to use the address stored in a register as the jump target.

[0130] The RET instruction indicates a return from a subroutine, jumping to the address in a register (such as the X30 register). This instruction can be an unconditional jump and contains a prompt indicating that this is a subroutine return.

[0131] From this, we can determine whether a function call or function return occurs by judging the assembly instruction corresponding to each trace data, and then gradually build the function call chain of the entire thread.

[0132] Therefore, in some embodiments, the construction process of the function call chain of each thread may include: reading a piece of tracing data and initializing it as a target node; reading the next piece of tracing data as the current tracing data; if it is determined that there is a function call based on at least the assembly instruction of the latest tracing data in the current target node, then generating a child node of the target node based on the assembly instruction of the current tracing data, and using the child node as the new target node; if it is determined that there is a function return based on at least the assembly instruction of the latest tracing data in the current target node, then using the parent node of the current target node as the new target node, and updating the new target node based on the assembly instruction of the current tracing data; if the assembly instruction of the latest tracing data in the current target node is neither a call instruction nor a return instruction, then updating the current target node based on the assembly instruction of the current tracing data; returning to the step of reading the next piece of tracing data as the current tracing data and continuing to execute until all tracing data are processed to obtain a function call relationship tree; the function call relationship tree represents the function call chain.

[0133] For each thread, the computer device can build a corresponding function call chain in the following way:

[0134] Construct a node, read the first trace data from the multiple trace data of the thread in time sequence, and initialize the node based on the read trace data, using the node as the initial target node. For example, store the relevant information of the read trace data (such as address information and assembly instructions, etc.) in the node, and control the target pointer (such as the cur pointer) to point to the node. It should be noted that the node pointed to by the target pointer is the target node in this application.

[0135] The computer device can read the next piece of tracing data as the current tracing data. Furthermore, it can determine whether a function call or function return exists based on at least the most recently stored assembly instruction in the target node. If a function call exists, a child node of the target node is generated based on the current tracing data, and the target pointer is set to point to the child node (that is, the child node is used as the new target node). If a function return exists, the target instruction is set to point to the parent node of the current target node (that is, the parent node of the current target node is used as the new target node), and the relevant information of the current tracing data (such as address information and assembly instruction, etc.) is stored in the new target node. If the assembly instruction of the most recently stored tracing data in the current target node is neither a call instruction nor a return instruction, the current target node is updated based on the current tracing data (the target pointer does not move) (specifically, the relevant information of the current tracing data can be stored in the target node). At this point, when the processing is completed, the computer device can read the next piece of tracing data as the new current tracing data and continue processing. In this way, new nodes and parent-child relationships between nodes are continuously constructed, and a function call relationship tree can be obtained after processing all tracing data. This function call relationship tree represents the function call chain. It can be understood that there is a calling relationship between the connected nodes in the function call relationship tree, that is, the function corresponding to the parent node calls the function corresponding to its child node.

[0136] In some embodiments, whether a function call exists is determined based at least on the latest assembly instruction stored in the target node, including: if the assembly instruction of the latest tracing data in the current target node is a first call instruction and there is an address match with the current tracing data, then it is determined that a function call exists; if the assembly instruction of the latest tracing data in the current target node is a second call instruction, then it is determined that a function call exists.

[0137] The call instruction includes a first call instruction and a second call instruction. The first call instruction is used to instruct a jump to an offset relative to the current PC position, which can be used to represent a static function call, and the first call instruction is, for example, a BL instruction; the second call instruction is used to instruct a jump to an address stored in a register, which can be used to represent a dynamic function call, and the second call instruction is, for example, a BLR instruction.

[0138] Specifically, when the computer device determines that the most recently stored assembly instruction in the current target node is the first call instruction, it is necessary to further determine whether there is an address match between the most recently stored trace data in the target node and the current trace data, that is, to determine whether the destination address target_addr corresponding to the first call instruction is equal to the starting address start_addr of the current trace data. If the destination address corresponding to the first call instruction is equal to the starting address of the current trace data, it is determined that there is an address match; if not, it is determined that there is no address match. The destination address target_addr corresponding to the first call instruction can specifically be an operand of the first call instruction obtained by disassembly.

[0139] This is because: for the first jump instruction, such as the BL instruction, its operand is an immediate number, which is the destination address of the jump. When the thread classification is correct, in a thread, function calls and function returns occur sequentially and linearly, so when the current tracing data (that is, the latest tracing data in the target node) is the first call instruction (such as the BL instruction), the starting address start_addr of the subsequent tracing data (that is, the current tracing data) is theoretically equal to the destination address of the first call instruction. If they are not equal, it means that the two tracing data do not belong to the same thread or data loss occurs. Therefore, when the assembly instruction of the latest tracing data in the current target node is the first call instruction, it is possible to determine whether there is a call relationship between the function corresponding to the current tracing data and the function corresponding to the tracing data by address matching.

[0140] If the assembly instruction of the latest trace data in the current target node is the second call instruction, since the second call instruction is used to indicate a jump to the address stored in the register, there is no address matching relationship between the subsequent trace data and the trace data, so it can be directly determined that a function call exists.

[0141] In the above embodiment, by instruction judgment or in combination with address matching, it is possible to accurately and quickly determine whether there is a function call between two pieces of tracking data, and then determine the parent-child relationship between different nodes, so as to construct a function call relationship tree.

[0142] In some embodiments, the process of determining the existence of a function return based at least on the assembly instruction of the latest tracing data in the current target node specifically includes: if the assembly instruction of the latest tracing data in the current target node is a return instruction and there is an address match with the current tracing data, then it is determined that there is a function return.

[0143] If the assembly instruction of the latest trace data in the current target node is a return instruction (RET instruction), the computer device performs address matching in the following manner: determining whether the target address target_addr corresponding to the return instruction is equal to the starting address start_addr of the current trace data; if the target address corresponding to the return instruction is equal to the starting address of the current trace data, then it is determined that an address match exists; if not, then it is determined that no address match exists. Wherein, the target address corresponding to the return instruction is a function return address, and the function return address can be determined in the following manner: searching the caller of the function corresponding to the return instruction (i.e., the parent node of the current target node) in the constructed function call relationship tree to obtain the address when the function is called (i.e., the end address end_addr of the latest trace data in the parent node), and determining the function return address based on the address when the function is called (i.e., the next address of the address when the function is called, i.e., determined by the sum of the end address of the latest trace data in the parent node of the current target node and the instruction length); if the starting address of the current trace data is equal to the function return address, then it is determined that an address match exists between the latest trace data in the current target node and the current trace data.

[0144] For example, if the assembly instruction of the latest trace data in the current target node is a return instruction (such as a RET instruction), the computer device can find the caller of the function corresponding to the RET instruction in the constructed function call relationship tree, obtain the address when the function was called, and obtain the function return address based on the address when the function was called (because the next address of the current PC pointer is used as the function return address when the function is called, so we obtain the function return address target_addr). The starting address start_addr of the next trace data (i.e., the current trace data) must be equal to the function return address target_addr to indicate that there is an address match between the two trace data. Otherwise, it indicates that the two trace data do not belong to the same thread or data loss has occurred. If the caller of the function corresponding to the RET instruction cannot be found in the currently constructed function call relationship tree, no address match is performed, and the next trace data (i.e., the current trace data) is deemed to be the function return address. After confirming that there is an address match between the two trace data, a function call relationship is then constructed in the function call relationship tree.

[0145] In the above embodiment, by identifying the assembly instructions of the latest tracing data in the target node, and further performing address matching in combination with the next tracing data (i.e., the current tracing data) of the latest tracing data in the target node, it is possible to accurately determine whether there is a call and / or return relationship between the two tracing data, thereby updating the target node and / or constructing the parent / child node of the target node, thereby gradually building up the function call chain of the entire thread.

[0146] In a specific embodiment, please refer to Figure 6 , which shows the construction process of the function call relationship tree of any thread:

[0147] Step 602: Read in a piece of tracking data and initialize it as a target node.

[0148] Step 604: Read the next piece of tracking data as the current tracking data.

[0149] Step 606 : Determine whether the assembly instruction of the latest trace data in the target node is a BL instruction. If so, proceed to step 608 ; otherwise, proceed to step 610 .

[0150] Step 608 : Determine whether the latest tracking data in the target node has an address match with the current tracking data. If so, proceed to step 612 ; otherwise, proceed to step 614 .

[0151] Step 610 : Determine whether the assembly instruction of the latest trace data in the target node is a BRL instruction. If so, proceed to step 612 ; otherwise, proceed to step 616 .

[0152] Step 612: Determine that a function call occurs, generate a calling child node, and set the target pointer to the child node (ie, use the child node as a new target node).

[0153] Step 614: Save the current function call chain and create a new node of the function call chain.

[0154] Step 616 : Determine whether the assembly instruction of the latest trace data in the target node is a RET instruction. If so, proceed to step 620 ; otherwise, proceed to step 618 .

[0155] Step 618: Update the target node according to the current tracking data.

[0156] Step 620 : Determine whether the latest tracking data in the target node has an address match with the current tracking data. If so, proceed to step 622 ; if not, proceed to step 624 .

[0157] Step 622: Determine that a function return occurs, and the target pointer points to the parent node (ie, the parent node is used as the new target node).

[0158] Step 624: Save the current function call chain and create a new node of the function call chain.

[0159] After step 612, step 614, step 618, step 622, and step 624 are completed, the process proceeds to step 626: determining whether all the tracking data have been processed. If so, the process ends; if not, the process returns to step 604 to continue execution.

[0160] It is understood that the present application does not limit the timing of the BL instruction determination step, the BLR instruction determination step, and the RET instruction determination step in the above process. Figure 6 It is only used for exemplary description. In actual applications, different judgment timings can also be adopted. For example, the judgment step of the BLR instruction is first and the judgment step of the BL instruction is later, or the judgment step of the RET instruction is executed first, and then the judgment steps of the BL instruction and the BLR instruction are executed, etc., or one or more instructions can be executed synchronously, etc., which can be adjusted based on actual needs.

[0161] For example, refer to Figure 7 , Figure 7 The figure is a schematic diagram illustrating function calls and function returns during the process of building a function call chain in one embodiment. When the target pointer changes, a solid arrow indicates that the target pointer points from the target node to the node's child node (i.e., a function call occurs), and a dashed arrow indicates that the target pointer points from the target node to the node's parent node (i.e., a function return occurs).

[0162] For the above-mentioned construction process, the function call relationship tree can usually be constructed step by step, but in some cases, the address matching may fail. For example, when the CPU frequency is very fast, the generated tracking data is too much, resulting in part of the tracking data being overwritten before being transferred, and then causing part of the tracking data to be lost. For this situation, the method also includes the steps of constructing a function call subtree and merging the function call subtrees, which includes the following steps: if the assembly instruction of the latest tracking data in the current target node is the first call instruction, and there is no address match with the current tracking data, then save the function call subtree that has been constructed; if the assembly instruction of the latest tracking data in the current target node is a return instruction, and there is no address match with the current tracking data, then save the function call subtree that has been constructed; merge the function call subtrees, and obtain the function call relationship tree based on the merge result.

[0163] Specifically, when an address match fails, the computer device can save the already constructed function call relationship tree and rebuild a new function call relationship tree starting from the unmatched trace data. These saved function call relationship trees are called function call subtrees, and the computer device can merge these function call subtrees to obtain the final function call relationship tree based on the merged results.

[0164] In some embodiments, the step of merging these function call subtrees may specifically include: traversing the function call subtree list to obtain two function call subtrees; determining whether the addresses of the two function call subtrees match, and if so, merging the function call subtrees and updating the function call subtree list; if not, returning to the step of obtaining the two function call subtrees and continuing to execute until the traversal of the function call subtree list is completed. If a merger occurs for the function call subtrees in the function call subtree list, the function call subtree list is updated based on the merger result, thereby restarting the traversal of the updated function call subtree list and continuing to execute. This iteration is continued until there are no function call subtrees that can be merged, and the final function call relationship tree can be obtained.

[0165] For example, refer to Figure 8 , Figure 8 FIG. 4 shows the steps of merging function call subtrees in one embodiment, as shown in FIG. Figure 8 As shown:

[0166] Step 802: Traverse the function call subtree list.

[0167] Step 804: Obtain two function call subtrees.

[0168] Step 806: Determine whether the addresses of the two function call subtrees match. If they do, proceed to step 810; if they do not, proceed to step 808.

[0169] Step 808: Determine whether the traversal of the function call subtree is complete. If the traversal is complete, the process ends. If not, return to step 804 to continue execution.

[0170] Step 810: Merge function call subtrees.

[0171] Step 812: Update the function call subtree list.

[0172] In some embodiments, the computer device may process each two subtrees in the function call subtree, and merge them if the two function call subtrees meet the merge condition. Determining whether two function call subtrees meet the merge condition may specifically include the following steps: determining whether there is an address match between the end node of the first function call subtree and the start node of the second function call subtree, and if there is an address match, determining whether the node in the first path of the first function call subtree matches the node in the second path of the second function call subtree, and if there is a match, merging the first function call subtree and the second function call subtree. Among them, the first path is the path from the end node of the first function call subtree to the start node (that is, the root node) of the first function call subtree; the second path is the path from the start node of the second function call subtree to the end node of the second function call subtree. It should be noted that the first function call subtree and the second function call subtree can be any two different function call subtrees.

[0173] Wherein, determining whether there is an address match between the end node of the first function call subtree and the start node of the second function call subtree may specifically include: determining whether the destination address target_addr of the end node of the first function call subtree is equal to the start address start_addr of the second function call subtree; if the destination address of the end node of the first function call subtree is equal to the start address of the second function call subtree, then determining that there is an address match; otherwise determining that there is no address match. If the end node of the first function call subtree corresponds to the first call instruction (such as the BL instruction), then the destination address is the operand of the first call instruction; if the end node of the first function call subtree corresponds to the return instruction (such as the RET instruction), then the destination address is the function return address (i.e., the sum of the end address of the parent node of the end node of the first function call subtree and the instruction length).

[0174] Furthermore, determining whether a node in the first path of the first function call subtree matches a node in the second path of the second function call subtree may specifically include the following steps:

[0175] If the end node of the first function call subtree corresponds to the first call instruction, then determine whether the end node matches the parent node of the start node of the second function call subtree. If they match, continue to recursively search the parent node for the first path and the second path to perform node matching processing until the parent node is not found. Among them, whether the end node of the first function call subtree matches the parent node of the start node of the second function call subtree can be determined specifically by the following steps: determine whether the next instruction address of the end node of the first function call subtree (that is, the sum of the end address end_addr of the end node and the instruction length) is equal to the start address start_addr of the parent node of the start node of the second function call subtree. If they are equal, it is determined that the nodes match; if they are not equal, it is determined that the nodes do not match.

[0176] If the end node of the first function call subtree corresponds to a return instruction, determine whether the parent node of the end node of the first function call subtree matches the start node of the second function call subtree. If they match, continue to recursively search the parent node for the first path and the second path to perform node matching processing until the parent node is not found. Among them, whether the parent node of the end node of the first function call subtree matches the start node of the second function call subtree can be determined specifically by the following steps: determine whether the next instruction address of the parent node of the end node of the first function call subtree (that is, the sum of the end address end_addr of the parent node of the end node and the instruction length) is equal to the start address start_addr of the start node of the second function call subtree. If they are equal, it is determined that the nodes match; if they are not equal, it is determined that the nodes do not match.

[0177] The following example illustrates the merging process of two function call subtrees in more detail:

[0178] In order to better process the call subtree later, each function call subtree can be set with a start pointer and an end pointer, pointing to the start node and end node of the function call subtree respectively. In addition, it should be noted that because the function call subtree is only generated when the address match fails, the end node of each function call subtree is either the address match failure of the first call instruction (such as the BL instruction) or the address match failure of the return instruction (such as the RET instruction).

[0179] Therefore, when merging two function call subtrees, it is possible to determine whether the addresses of the end node of the first function call subtree match the start node of the second function call subtree. The address matching rules are consistent with those used when calculating a function call chain: If the end node of the first function call subtree is a BL jump, the BL destination address is calculated to see if it matches the start address of the start node of the second function call subtree; if the end node of the first call subtree is a RET jump, the function return address is calculated to see if it matches the start address of the start node of the second function call subtree. Once the addresses of the end node of the first function call subtree and the start node of the second function call subtree match, it is necessary to determine whether the other nodes of the two function call subtrees match. If all other nodes match, the two function call subtrees can be merged. If any nodes do match during the recursive process, the two function call subtrees cannot be merged. When all nodes match successfully, the two function call subtrees are merged into one function call tree. By merging the function call subtrees, all possible data is spliced ​​together, and the entire function call chain calculation is completed.

[0180] by Figure 9 For example, please refer to Figure 9 , Figure 9 This is an example of two function call subtrees in one embodiment. Figure 9 As shown, node a in function call subtree 1 calls node b, node c, and node d respectively, node c calls node e, and node d calls node f, where node a is the start node and node f is the end node; node A in function call subtree 2 calls node B, node C, and node D respectively, node B calls nodes E and F, node C calls node G, node D calls node H, and node E calls node I, where node I is the start node and node A is the end node.

[0181] When the address of the end node of function call subtree 1 matches the address of the start node of function call subtree 2, it is necessary to compare whether their corresponding parent nodes match. In the figure, node f is a BL jump and matches the address of node I. This indicates that node f may be the parent node of node I, so node f and node E may be the same function. If the address of node f's BL instruction (end_addr) plus the instruction length (i.e., the function return address) equals the start address of node E, then the start address of node E is the function return address, indicating that after the function of node f calls the function of node I, the function returns to node E. Similarly, the addresses of the parent nodes of nodes f and E are compared to see if they match. Address matching is performed by continuously recursively matching the parent nodes until one of the subtrees does not have a parent node. If there is an address mismatch during the recursive process, it means that the two subtrees cannot be merged. When all addresses match successfully, the two function call subtrees are merged into one call tree.

[0182] In the above embodiment, when determining function call and / or function return relationships, if an address mismatch occurs, a function call subtree is directly generated. After all trace data is processed, multiple function call subtrees may be obtained. Then, the function call subtrees are merged, and the mergeable data can be merged to obtain a more complete function call relationship tree.

[0183] In some embodiments, as described above, a function call chain can be represented by a function call relationship tree, where each node in the function call relationship tree represents a function corresponding to a tracing data. For each node, the computer device can store the tracing data corresponding to the node (including the virtual address range of the corresponding function), and the function name and / or source code file path and code line number corresponding to the tracing data in the node, and use the corresponding function name to represent the node name, so that analysts can easily understand the function call chain represented by the function call relationship tree, and quickly locate the source code files and codes.

[0184] Furthermore, in actual applications, it is possible to obtain the full amount of tracing data of a program as needed, and then obtain the function call chain of the program. The obtained program function call chain can be used to verify whether the execution of the program is logical.

[0185] In other application scenarios, when the system running the program fails or crashes, the tracking data of the specified process related to the failure or crash can be obtained through configuration, and then the function call chain related to the specified process can be obtained, so as to locate and analyze the failure based on the function call chain.

[0186] In some application scenarios, based on business needs, you can obtain the full amount of tracing data or the tracing data of a specified process for analysis to obtain the corresponding function call chain. Then, based on the function call chain, you can analyze the execution status of each function, such as the execution time of each function, to optimize the function in a targeted manner.

[0187] It can be understood that the method for determining the function call chain provided in the embodiment of the present application is not limited to the above-mentioned application scenarios. The above-mentioned application scenarios are only used for illustrative purposes and are not limiting. The method provided in the present application can be applied to any suitable and necessary scenarios.

[0188] In a specific embodiment, the method for determining the function call chain includes the following steps:

[0189] Mapping information is searched based on the process ID of the specified process to determine the specified virtual address of the specified process according to the found mapping information; based on the process ID and the specified virtual address, tracking data to be analyzed related to the specified process generated during program execution is obtained.

[0190] Determining the ELF files corresponding to the respective trace data from a memory dump file associated with the program; determining the offset addresses of the respective trace data to be analyzed in the corresponding ELF files; and performing disassembly based on the ELF files corresponding to the respective trace data to be analyzed and the offset addresses in the corresponding ELF files to obtain the assembly instructions corresponding to the respective trace data to be analyzed. If the ELF file includes symbol information, parsing the symbol information to obtain the function symbols corresponding to the respective trace data, and / or, if the ELF file includes debugging information, parsing the debugging information to obtain the function symbols corresponding to the respective trace data, as well as the source code file paths and code line numbers.

[0191] Obtain the current tracing data to be classified from multiple tracing data to be analyzed; determine the decision rule used in the current judgment according to the priority order of multiple decision rules; based on the determined decision rule, compare the tracing data to be classified with the last tracing data of each thread in the current thread list to determine whether the tracing data to be classified belongs to any thread in the current thread list; if the thread to which the tracing data to be classified belongs is found in the current judgment, stop; otherwise, return to the step of determining the decision rule used in the current judgment according to the priority order of multiple decision rules and continue to execute for re-judgment. If the tracing data to be classified belongs to any thread in the current thread list, classify the tracing data to be classified into the thread; if not, classify the tracing data to be classified into a new thread; return to the step of obtaining the current tracing data to be classified from the multiple tracing data to be analyzed and continue to execute until the classification of all the tracing data to be analyzed is completed.

[0192] The last trace data of the thread is used as the first trace data, and the trace data to be classified is used as the second trace data. The multiple determination rules include the following rules: a first determination rule: if the first trace data does not jump abnormally, the first trace data and the second trace data correspond to the same processor core, and the first trace data and the second trace data are continuous in time sequence, then the second trace data is determined to belong to the thread to which the first trace data belongs; a second determination rule: if the first trace data jumps abnormally, the first trace data and the second trace data correspond to the same processor core, and there is an address match between the first trace data and the second trace data, then the second trace data is determined to belong to the thread to which the first trace data belongs; a third determination rule: if the first trace data jumps abnormally, the first trace data and the second trace data correspond to different processor cores, and there is an address match between the first trace data and the second trace data, then the second trace data is determined to belong to the thread to which the first trace data belongs; wherein the priority of the first determination rule is greater than the priority of the second determination rule, and the priority of the second determination rule is greater than the priority of the third determination rule.

[0193] For each thread, the function call relationship analysis is performed based on the assembly instructions of the corresponding thread's trace data to obtain the function call chain of the corresponding thread. The process of determining the function call chain of each thread includes:

[0194] Read a trace data and initialize it as the target node.

[0195] Read the next trace data as the current trace data.

[0196] If the assembly instruction of the latest tracing data in the current target node is the first call instruction and there is an address match with the current tracing data, a child node of the target node is generated based on the assembly instruction of the current tracing data, and the child node is used as the new target node; if the assembly instruction of the latest tracing data in the current target node is the first call instruction and there is no address match with the current tracing data, the constructed function call subtree is saved.

[0197] If the assembly instruction of the latest tracing data in the current target node is the second call instruction, a child node of the target node is generated based on the assembly instruction of the current tracing data, and the child node is used as a new target node.

[0198] If the assembly instruction of the latest tracing data in the current target node is a return instruction and there is an address match with the current tracing data, the parent node of the current target node is used as the new target node, and the new target node is updated based on the assembly instruction of the current tracing data; if the assembly instruction of the latest tracing data in the current target node is a return instruction and there is no address match with the current tracing data, the constructed function call subtree is saved.

[0199] If the assembly instruction of the latest trace data in the current target node is neither a call instruction nor a return instruction, the current target node is updated based on the assembly instruction of the current trace data.

[0200] Return to read the next trace data as the step of current trace data and continue to execute until all trace data are processed to obtain a function call relationship tree; the function call relationship tree represents the function call chain.

[0201] This method uses the ARM Coresight hardware component to obtain the virtual address of the instruction executed on the CPU core. Combined with the process map information, the code segment offset address of the instruction in the ELF file can be calculated. The assembly instructions can then be disassembled using the code segment offset address and the ELF file specified in the process map information. By analyzing the assembly instructions and continuously counting function calls and function returns, the function call chain of a program during execution can be gradually calculated. This approach allows Coresight Trace to accurately calculate the function call chain with little impact on system performance, and further accurately track all program behaviors through the function call chain.

[0202] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0203] Based on the same inventive concept, embodiments of the present application also provide a device for determining a function call chain for implementing the aforementioned method for determining a function call chain. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of the embodiments of one or more device for determining a function call chain provided below can be found in the aforementioned limitations of the method for determining a function call chain, and will not be further elaborated here.

[0204] In an exemplary embodiment, Figure 10 As shown, a device 1000 for determining a function call chain is provided, comprising: an acquisition module 1001, a determination module 1002, a classification module 1003, and a construction module 1004, wherein:

[0205] The acquisition module is used to obtain the tracking data to be analyzed during the program running process.

[0206] The determination module is used to determine the assembly instruction corresponding to each trace data to be analyzed based on a memory dump file related to the program.

[0207] The classification module is used to classify the tracing data to be analyzed by thread and obtain the tracing data of each thread.

[0208] A building module is used to perform function call relationship analysis on each thread based on the assembly instructions of the tracking data of the corresponding thread to obtain the function call chain of the corresponding thread.

[0209] In one embodiment, the acquisition module is specifically used to: search for mapping information based on the process identifier of the specified process to determine the specified virtual address of the specified process based on the found mapping information; based on the process identifier and the specified virtual address, obtain the tracking data to be analyzed related to the specified process generated during the program running process.

[0210] In some embodiments, the determination module is specifically used to: determine the ELF files corresponding to each piece of tracing data from a memory dump file related to the program; determine the offset address of each piece of tracing data to be analyzed in the corresponding ELF file; and perform disassembly based on the ELF file corresponding to each piece of tracing data to be analyzed and the offset address in the corresponding ELF file to obtain the assembly instructions corresponding to each piece of tracing data to be analyzed.

[0211] In some embodiments, the determination module is further used to: if the ELF file includes symbol information, parse the symbol information to obtain the function symbols corresponding to each tracing data, and / or, if the ELF file includes debugging information, parse the debugging information to obtain the function symbols corresponding to each tracing data, as well as the source code file path and code line number.

[0212] In some embodiments, the classification module is specifically used to: obtain the current tracing data to be classified from multiple tracing data to be analyzed; determine whether the tracing data to be classified belongs to any thread in the current thread list, and if so, classify the tracing data to be classified into the thread; if not, classify the tracing data to be classified into a new thread; return to obtain the current tracing data to be classified from the multiple tracing data to be analyzed and continue execution until the classification of all tracing data to be analyzed is completed.

[0213] In some embodiments, the classification module is further specifically used to: determine the determination rule used in the current determination according to the priority order of multiple determination rules; based on the determined determination rule, compare the tracking data to be classified with the last tracking data of each thread in the current thread list to determine whether the tracking data to be classified belongs to any thread in the current thread list; if the thread to which the tracking data to be classified belongs is found in the current determination, stop; otherwise, return to the step of determining the determination rule used in the current determination according to the priority order of multiple determination rules and continue to execute for re-determination.

[0214] In some embodiments, the last trace data of a thread is used as the first trace data, and the trace data to be classified is used as the second trace data. A first determination rule is as follows: if the first trace data does not undergo an abnormal jump, the first trace data and the second trace data correspond to the same processor core, and the first trace data and the second trace data are continuous in time sequence, then the second trace data is determined to belong to the thread to which the first trace data belongs. A second determination rule is as follows: if the first trace data undergoes an abnormal jump, the first trace data and the second trace data correspond to the same processor core, and there is an address match between the first trace data and the second trace data, then the second trace data is determined to belong to the thread to which the first trace data belongs. A third determination rule is as follows: if the first trace data undergoes an abnormal jump, the first trace data and the second trace data correspond to different processor cores, and there is an address match between the first trace data and the second trace data, then the second trace data is determined to belong to the thread to which the first trace data belongs. The priority of the first determination rule is greater than the priority of the second determination rule, and the priority of the second determination rule is greater than the priority of the third determination rule.

[0215] In some embodiments, the construction module is specifically used to: read a piece of tracing data and initialize it as a target node; read the next piece of tracing data as the current tracing data; if it is determined that there is a function call based on at least the assembly instruction of the latest tracing data in the current target node, then generate a child node of the target node based on the assembly instruction of the current tracing data, and use the child node as the new target node; if it is determined that there is a function return based on at least the assembly instruction of the latest tracing data in the current target node, then use the parent node of the current target node as the new target node, and update the new target node based on the assembly instruction of the current tracing data; if the assembly instruction of the latest tracing data in the current target node is neither a call instruction nor a return instruction, then update the current target node based on the assembly instruction of the current tracing data; return to the step of reading the next piece of tracing data as the current tracing data and continue executing until all tracing data are processed to obtain a function call relationship tree; the function call relationship tree represents the function call chain.

[0216] In some embodiments, the construction module is also specifically used to: if the assembly instruction of the latest tracing data in the current target node is a first call instruction and there is an address match with the current tracing data, then it is determined that there is a function call; if the assembly instruction of the latest tracing data in the current target node is a second call instruction, then it is determined that there is a function call; if the assembly instruction of the latest tracing data in the current target node is a return instruction and there is an address match with the current tracing data, then it is determined that there is a function return.

[0217] In some embodiments, the construction module is also specifically used to: if the assembly instruction of the latest tracing data in the current target node is the first call instruction, and there is no address match with the current tracing data, then save the constructed function call subtree; if the assembly instruction of the latest tracing data in the current target node is a return instruction, and there is no address match with the current tracing data, then save the constructed function call subtree; merge the function call subtrees, and obtain a function call relationship tree based on the merging result.

[0218] Each module in the aforementioned function call chain determination device may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor in a computer device in the form of hardware, or may be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0219] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal or a server, and its internal structure diagram may be as follows: Figure 11 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for determining a function call chain is implemented.

[0220] Those skilled in the art will understand that Figure 11 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0221] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0222] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0223] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0224] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0225] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile memory and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable logic unit (PLC), a data processing logic unit based on quantum computing, an artificial intelligence (AI) processor, and the like.

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

[0227] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.< / pid>

Claims

1. A method for determining a function call chain, characterized in that: The method comprises: Obtain the tracking data to be analyzed during the program running; Determining, based on a memory dump file associated with the program, an assembly instruction corresponding to each trace data to be analyzed; Classifying the tracing data to be analyzed by thread to obtain tracing data of each thread; For each thread, a function call relationship analysis is performed based on the assembly instructions of the corresponding thread's tracking data to obtain the function call chain of the corresponding thread.

2. The method according to claim 1, characterized in that The acquisition of the tracking data to be analyzed generated during the program execution includes: Searching for mapping information based on the process identifier of the designated process, so as to determine the designated virtual address of the designated process according to the found mapping information; Based on the process identifier and the designated virtual address, tracking data to be analyzed that is generated during program execution and is related to the designated process is obtained.

3. The method according to claim 1, characterized in that The step of determining, based on a memory dump file related to the program, the assembly instruction corresponding to each piece of trace data to be analyzed, includes: Determine the ELF files corresponding to the respective trace data from the memory dump file related to the program; Determine the offset address of each trace data to be analyzed in the corresponding ELF file; Disassembly is performed based on the ELF file corresponding to each piece of tracing data to be analyzed and the offset address in the corresponding ELF file to obtain the assembly instruction corresponding to each piece of tracing data to be analyzed.

4. The method according to claim 3, characterized in that The method further comprises: If the ELF file includes symbol information, the symbol information is parsed to obtain the function symbols corresponding to each trace data, and / or, If the ELF file includes debugging information, the debugging information is parsed to obtain the function symbols, source code file paths, and code line numbers corresponding to each trace data.

5. The method according to claim 1, wherein The tracing data to be analyzed is classified by thread to obtain tracing data of each thread, including: Obtaining current tracking data to be classified from multiple tracking data to be analyzed; Determine whether the tracing data to be classified belongs to any thread in the current thread list, if so, classify the tracing data to be classified into the thread; if not, classify the tracing data to be classified into a new thread; Return to the step of obtaining the current tracing data to be classified from the plurality of tracing data to be analyzed and continue the process until the classification of all the tracing data to be analyzed is completed.

6. The method according to claim 5, characterized in that Determining whether the tracking data to be classified belongs to any thread in the current thread list includes: Determine the decision rule to be used in the current decision according to the priority order of the multiple decision rules; Based on the determined judgment rule, the tracking data to be classified is compared with the last tracking data of each thread in the current thread list to determine whether the tracking data to be classified belongs to any thread in the current thread list; If the thread to which the tracking data to be classified belongs is found in the current determination, the process stops; otherwise, the process returns to the step of determining the determination rule used in the current determination according to the priority order of the multiple determination rules and continues to perform another determination.

7. The method according to claim 6, characterized in that The last trace data of the thread is used as the first trace data, and the trace data to be classified is used as the second trace data. The multiple determination rules include the following rules: A first determination rule: if the first tracing data does not undergo an abnormal jump, the first tracing data and the second tracing data correspond to the same processor core, and the first tracing data and the second tracing data are sequentially continuous, then determining that the second tracing data belongs to the thread to which the first tracing data belongs; A second determination rule: if an abnormal jump occurs in the first tracing data, the first tracing data and the second tracing data correspond to the same processor core, and there is an address match between the first tracing data and the second tracing data, then determining that the second tracing data belongs to the thread to which the first tracing data belongs; A third determination rule: if the first tracing data jumps abnormally, the first tracing data and the second tracing data correspond to different processor cores, and there is an address match between the first tracing data and the second tracing data, then it is determined that the second tracing data belongs to the thread to which the first tracing data belongs; The priority of the first determination rule is higher than that of the second determination rule, and the priority of the second determination rule is higher than that of the third determination rule.

8. The method according to claim 1, characterized in that The process of determining the function call chain of each thread includes: Read a trace data and initialize it as the target node; Read the next tracking data as the current tracking data; If it is determined that a function call exists based on at least the assembly instructions of the latest tracing data in the current target node, generating a child node of the target node based on the assembly instructions of the current tracing data, and using the child node as a new target node; If it is determined that a function return exists based on at least the assembly instructions of the latest tracing data in the current target node, the parent node of the current target node is used as a new target node, and the new target node is updated based on the assembly instructions of the current tracing data; If the assembly instruction of the latest tracing data in the current target node is neither a call instruction nor a return instruction, updating the current target node based on the assembly instruction of the current tracing data; Return to the step of reading the next piece of tracing data as the current tracing data and continue executing until all tracing data are processed to obtain a function call relationship tree; the function call relationship tree represents the function call chain.

9. The method according to claim 8, characterized in that The process of determining whether a function call exists includes: If the assembly instruction of the latest trace data in the current target node is the first call instruction and there is an address match with the current trace data, then it is determined that a function call exists; If the assembly instruction of the latest trace data in the current target node is the second call instruction, it is determined that a function call exists; The process of determining whether a function returns a value includes: If the assembly instruction of the latest tracing data in the current target node is a return instruction and there is an address match with the current tracing data, it is determined that there is a function return.

10. The method according to claim 9, characterized in that The method further comprises: If the assembly instruction of the latest tracing data in the current target node is the first call instruction and there is no address match with the current tracing data, then saving the constructed function call subtree; If the assembly instruction of the latest trace data in the current target node is a return instruction and there is no address match with the current trace data, then save the constructed function call subtree; The function call subtrees are merged to obtain a function call relationship tree based on the merging result.

11. A device for determining a function call chain, characterized in that: The device comprises: The acquisition module is used to obtain the tracking data to be analyzed during the program running process; a determination module, configured to determine, based on a memory dump file associated with the program, an assembly instruction corresponding to each piece of trace data to be analyzed; A classification module, configured to classify the trace data to be analyzed by thread to obtain trace data of each thread; A building module is used to perform function call relationship analysis on each thread based on the assembly instructions of the tracking data of the corresponding thread to obtain the function call chain of the corresponding thread.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 10 are implemented.

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

14. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images