Method and system for checking consistency of control flows before and after program cross-platform transplantation

By performing source code instrumentation and event sequence analysis on the platforms before and after cross-platform software transplantation, the consistency check of the control flow is realized, which solves the problem of the inability to effectively check the consistency of the control flow in the existing technology and improves the efficiency of software transplantation. Quality assurance.

CN119336604APending Publication Date: 2025-01-21INST OF SOFTWARE - CHINESE ACAD OF SCI
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411360884.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-27
Publication Date
2025-01-21

AI Technical Summary

Technical Problem

During the cross-platform software transplantation process, the existing technology cannot effectively verify the consistency of the control flow, resulting in the software that may not fully utilize the performance of the new platform after the transplantation, and even runtime errors occur.

Method used

By compiling the source code for the target program to test before and after the transplantation of cross -platform transplants, and the piles are performed, the program can be executed after the piles can be performed, and the source code position information corresponding to the pile point position is recorded. Then, perform the program after inserting the pile, get the event sequence, analyze and restore the control flow information during runtime, and perform a comparative test to ensure the consistency of the control flow.

Benefits of technology

The consistency test of the control flow before and after the software cross -platform transplantation is realized, the quality of software transplantation quality is improved, and the reliability and recovery of the test results are ensured.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119336604A_ABST
    Figure CN119336604A_ABST
Patent Text Reader

Abstract

The invention discloses a control flow consistency checking method and system before and after program cross-platform transplantation, and belongs to the field of software testing and software transplantation. According to the method, on a platform before and after cross-platform transplantation, source codes of a target program to be tested are compiled and instrumented, program executable files after instrumentation are generated, and source code position information corresponding to each instrumentation point location is recorded; executing the program executable file after instrumentation to obtain an event sequence; the event sequence is scanned and analyzed, and control flow information during operation is restored for the to-be-tested target program before and after cross-platform transplantation; comparing and analyzing the control flow information before and after cross-platform transplantation, and checking whether the target program to be tested has control flow inconsistency or not; and if the control flows are inconsistent, positioning code positions where the control flows are inconsistent in the source codes according to the recorded source code position information, and generating a control flow inconsistent report. According to the method, the reliability of the control flow consistency check result before and after program cross-platform transplantation can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention belongs to the field of software testing and software transplantation, and particularly relates to control flow consistency checking before and after program cross-platform transplantation. Background Art

[0002] With the development of computer technology, in order to cope with increasingly complex application needs, a large number of new hardware platforms and underlying systems have emerged in the market, such as various new platforms and systems under the ARM and RISCV architectures. Through customized design, these new platforms and systems can make full use of the characteristics of the hardware platform and greatly improve the performance of the software running on it in certain specific aspects. These new hardware platforms and systems are currently being widely used in many fields such as high-performance computing, embedded devices, and mobile devices, and are showing a good development trend of continuing to enter other fields. However, the diversified development of such hardware platforms and underlying systems has brought difficulties to software development. Since most of these new platforms and systems adopt customized design, if you want to give full play to the characteristics of these new platforms and systems, developers need to make adaptive modifications to the source code of the software (hereinafter referred to as software transplantation) based on the differences between the original platform and the target new platform. In the process of software migration, if the developer makes incorrect adaptation modifications to the software source code due to insufficient understanding of the characteristics of the new platform, or if the developer fails to modify all source codes related to platform characteristics due to omissions in the programming process, the migrated software may not be able to fully utilize the performance advantages of the new platform, and may even cause the migrated software to encounter catastrophic errors such as runtime errors and unexpected operation results on the new platform. These difficulties make cross-platform software migration face huge challenges.

[0003] At present, there is no effective method for testing software migration. The method for testing the quality of software after cross-platform migration is mainly functional testing, that is, testing whether the various functional attributes of the software meet expectations on the platform after migration. However, this functional testing method has many hidden dangers. First, due to the differences in platforms and systems, the functional test components that run well on the original platform may not be able to run directly on the new platform without any modification. Therefore, the functional test components themselves also need to be migrated. Since there are no testing tools for functional test components, the migration quality of the functional test components themselves cannot be guaranteed, which also leads to doubts about the effectiveness and credibility of functional testing of software on the new platform. Secondly, functional testing cannot test whether all attributes of the software meet expectations, such as attributes such as performance overhead, or those functional attributes that cannot be externalized as visible outputs, so the test coverage of functional testing is also limited. The above two difficulties have posed challenges to how to ensure the quality of software after cross-platform migration. Summary of the invention

[0004] The purpose of the present invention is to provide a control flow consistency test method and system before and after program cross-platform migration, which can be used as a supplement to functional testing to test whether the program is consistent before and after cross-platform migration in the control flow dimension, thereby providing a higher guarantee for the quality of cross-platform software migration. The test method and system can ensure the reliability of the results, that is, all reported inconsistencies correspond to real control flow inconsistencies.

[0005] In order to simplify the description of the present invention, the following concepts are defined:

[0006] Event sequence: a sequential sequence composed of single events as elements; the order in which events appear in the event sequence represents the chronological order in which the events occur.

[0007] Event: Use the symbol e to represent an event in a sequence of events.

[0008] Branch jump event: used to record a control flow jump node of the program. Each branch jump event contains two attributes, namely the type of control flow jump and the condition of this control flow jump.

[0009] Function entry / exit events: used to record the program's function entry / exit behavior. Each function entry / exit event contains one attribute, which is the function that the program enters / exits.

[0010] Function stack status of an event: The function stack status of a program when it runs to a certain time point where an event e occurs. This is called the function stack status of the program at event e (abbreviated as the function stack status of event e), denoted by ρ(e). Using a function stack sequence [F1, F2, …, F n ] to represent the function stack status of event e, where each element F i Indicates a function that has been entered but not yet exited. F1 is the function at the bottom of the function stack. n The function at the top of the function stack.

[0011] Event sequence fragments: According to the function stack status of the event, the event sequence is divided into a series of continuous fragments with the same function stack status, using S i Indicates that each event sequence segment consists of a series of consecutive events with the same function stack status, namely S i =[e k ,e k+1 ,…,e l ], where e k ,e k+1 ,…,e l appear continuously in the event sequence and have the same function stack status, that is, ρ(e k )=ρ(e k+1)=…=ρ(e l ). The function stack state of each event sequence fragment S is defined as the same as the function stack state of all its events, that is, ρ(S) = ρ(e k )=ρ(e k+1 )=…=ρ(e l ).

[0012] Event sequence fragment sequence: It is composed of multiple event sequence fragments, represented as T = [S1, S2, ..., S n ], where each element S i Represents a fragment of a sequence of events.

[0013] Based on the above concepts, the present invention achieves the above objectives by adopting the following technical solutions:

[0014] A method for checking control flow consistency before and after program cross-platform migration comprises the following steps:

[0015] 1) On the platforms before and after the cross-platform transplantation, compile the target program source code to be tested and perform stub insertion, generate the program executable file after stub insertion, and record the source code location information corresponding to each stub insertion point;

[0016] 2) Execute the program executable file after the instrumentation to obtain the event sequence;

[0017] 3) Scan and analyze the event sequence to restore the runtime control flow information of the target program to be tested before and after the cross-platform transplantation, including the function stack status and the control flow path selection status within the function;

[0018] 4) Compare and analyze the control flow information before and after cross-platform transplantation to check whether there is any control flow inconsistency in the target program to be tested;

[0019] 5) If there is a control flow inconsistency, the code position where the control flow inconsistency occurs is located in the source code according to the recorded source code position information, and a control flow inconsistency report is generated.

[0020] Furthermore, the event sequence in step 1) includes: a branch jump event, a function entry event and a function exit event.

[0021] Furthermore, the source code location information in step 1) includes the file path, code line number and variable symbol name information of the source code.

[0022] Furthermore, in step 1), when compiling the source code of the target program to be tested, a stub code is inserted at each control flow jump of the program to record a control branch event, and a stub code is inserted at the entry and exit of the function to record function entry and function exit events; for a branch jump event, the type of the jump and the value of the conditional variable of the jump are recorded; for a function entry / exit event, the function entered / exited is recorded.

[0023] Furthermore, in step 2), the program executable file after the instrumentation is executed to generate a record file of events; the record file is read, and all events are sorted in chronological order from small to large to obtain an event sequence.

[0024] Furthermore, the step of restoring the control flow information at runtime in step 3) includes:

[0025] Scan the event sequence sequentially and calculate the function stack status of each event;

[0026] According to the function stack status information of the event, the event sequence is divided into a plurality of event sequence segments, each event sequence segment includes a series of events that are continuous in the event sequence and have the same function stack status;

[0027] Sequentially scan the branch jump information in each event sequence fragment to restore the control flow path selection status within the function.

[0028] Furthermore, the step of calculating the function stack status of each event includes:

[0029] Maintain a function stack sequence to represent the function stack status of the program at the time point of the event. Each element in the function stack sequence represents a function that has been entered but not yet exited;

[0030] The function stack sequence is initially empty and is gradually updated as the events in the event sequence are scanned. The updating method is as follows: when the scan advances to an event, if the event is a branch jump event, the function stack sequence is not updated; if the event is a function entry event, the entered function is added to the end of the function stack sequence; if the event is a function exit event, the exited function is removed from the end of the function stack sequence; when the scan reaches the event, the function stack sequence at this time is the function stack status of the event.

[0031] Furthermore, the step of checking whether the target program to be tested has control flow inconsistency in step 4) includes:

[0032] For the two event sequence fragment sequences before and after the cross-platform transplantation, firstly, the function stack states of the two event sequence fragments at the corresponding positions in the two event sequence fragment sequences are compared to see whether they are the same, and then the control flow path selection states in the functions are compared to see whether they are the same;

[0033] If the function stack states of the two event sequence fragments are different, a control flow inconsistency is reported in the target program to be tested, and the inconsistency check is suspended, and then an error rollback is attempted to resume the inconsistency check;

[0034] If the function stack conditions of the two event sequence fragments are the same, but there are differences in the control flow path selection conditions within the function, then further check the degree of the difference; if the difference causes control flow inconsistency, then report the inconsistency and suspend the inconsistency check, and then try error rollback to resume the inconsistency check; if the difference does not cause control flow inconsistency, then continue to compare the next pair of event sequence fragments;

[0035] If the function stack status and the control flow path selection status within the function of the two event sequence fragments are the same, it is considered that there is no cross-platform control flow inconsistency between the two event sequence fragments, and the next pair of event sequence fragments are compared;

[0036] When the above comparison reaches the end of one of the event sequences, the inconsistency check ends.

[0037] Furthermore, the step of comparing whether the control flow path selection conditions in the functions are the same includes:

[0038] Sequentially traverse all branch jump events in the two event sequence segments, first compare whether two branch jump events at corresponding positions in the two event sequence segments are completely identical in jump type and jump condition;

[0039] If the two branch jump events are different in jump type or jump condition, it is determined that there is a difference in the control flow path selection status within the function that causes the control flow inconsistency, the inconsistency is reported and the inconsistency check is suspended;

[0040] If the two branch jump events are completely identical in jump type and jump condition, then continue to compare the next pair of branch jump events;

[0041] When the comparison reaches the end of one of the event sequences, if no difference is found in the jump type or jump condition between the events, it is considered that there is no difference in the control flow path selection status within the function between the two event fragments that causes inconsistent control flow.

[0042] Furthermore, when a difference is detected, an inconsistency is reported and the inconsistency check is suspended, the impact of the inconsistency is eliminated in subsequent sequence segments and the inconsistency check is resumed by processing the following steps:

[0043] If control flow inconsistency is detected between the two event sequence segments, finding a longest common prefix sequence in the function stack states of the two event sequence segments;

[0044] If the longest common prefix sequence is empty, the inconsistency check ends;

[0045] If the longest common prefix sequence is not empty, the subsequent event sequence segments are sequentially scanned one by one in the two event sequence segment sequences to find the first event sequence segment S that meets the condition equal to the longest common prefix sequence. p and S′ q ; If the condition S is met p or S′ q If it does not exist, then end the inconsistency check, otherwise check S p and S′ q Whether there are control flow inconsistencies;

[0046] If S p and S′ q If there is a control flow inconsistency, repeat the above steps;

[0047] If S p and S′ q If there is no control flow inconsistency, resume the inconsistency check and continue with the second event sequence fragment S that satisfies the condition equal to the longest common prefix sequence. p+1 and S′ q+1 Perform control flow inconsistency checking on the

[0048] A control flow consistency verification system before and after program cross-platform migration, comprising:

[0049] The program instrumentation module is used to compile the target program source code and perform instrumentation on the platforms before and after cross-platform transplantation, generate the program executable file after instrumentation, and record the source code location information corresponding to each instrumentation point;

[0050] The sequence collection module is used to execute the program executable file after the instrumentation to obtain the event sequence;

[0051] The control flow consistency check module is used to scan and analyze the event sequence, and restore the runtime control flow information of the target program to be tested before and after the cross-platform transplantation, and the control flow information includes the function stack status and the control flow path selection status within the function; compare and analyze the control flow information before and after the cross-platform transplantation, and check whether there is any control flow inconsistency in the target program to be tested;

[0052] The report generation module is used to locate the code position where the control flow inconsistency occurs in the source code according to the recorded source code position information when a control flow inconsistency is detected, and to generate a control flow inconsistency report.

[0053] Compared with the prior art, the technical effects achieved by the present invention are as follows:

[0054] 1. The present invention specifically tests the consistency properties of software across platforms, overcoming the defect that the prior art cannot perform consistency testing across platforms.

[0055] 2. The control flow-based consistency detection scheme of the present invention has the advantages of strong versatility and good software / platform compatibility. Since the cross-platform transplantation of a program often does not modify the processing logic of the program itself, and the control flow is often not affected by the characteristics of specific software and platforms, the present invention can be applied to the cross-platform transplantation consistency detection of multiple hardware platforms and multiple user / system software.

[0056] 3. The present invention has the advantages of accurate detection granularity, high reliability and reproducibility of detection results. For each detected control flow inconsistency, the present invention displays detailed debugging information such as the specific code line related to the inconsistency, the runtime call chain, and the required running commands in the report, which can better help developers to stably reproduce the detected control flow inconsistencies.

[0057] 4. The present invention only performs inconsistency checks on internal properties such as program control flow, and does not check external properties such as program functions and outputs. Therefore, it has the advantage of being able to complement other cross-platform software quality inspection technologies based on functional testing and unit testing, and collaboratively ensure the quality of cross-platform porting software. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 The present invention is a flowchart of a control flow consistency check before and after a program is transplanted across platforms. DETAILED DESCRIPTION

[0059] In order to make the various technical features and advantages or technical effects in the technical solution of the present invention more obvious and easy to understand, they are described in detail below with reference to the accompanying drawings.

[0060] An embodiment of the present invention discloses a method for checking control flow consistency before and after a program is transplanted across platforms. The processing steps are divided into four stages: source code insertion, sequence collection, control flow inconsistency detection, and report generation. The control flow inconsistency detection is based on a set of predefined verification rules. The rules can be further expanded in a modular manner to achieve more effective or customized inconsistency detection requirements.

[0061] 1. Source code instrumentation stage

[0062] On the platforms before and after cross-platform transplantation, the source code of the target program to be tested is compiled and inserted respectively to generate the executable file of the program after insertion, and the source code location information corresponding to each insertion point (also known as control flow node) is recorded and stored in the source code location information database. The source code location information includes the file path, code line number, variable symbol name and other information of the corresponding source code. When the source code is compiled, the insertion code is inserted at each control flow jump of the program to record the control branch event, and the insertion code is inserted at the entry and exit of the function to record the function entry and function exit events. Among them, for the branch jump event, it is necessary to record the jump type (including unconditional jump goto, two-way branch jump br, multi-way branch jump switch and non-direct jump indirect) and the conditional variable value of the jump. For function entry and function exit events, it is necessary to record the entry and exit functions. Each insertion recording point needs to record the corresponding source code location information.

[0063] 2. Sequence Collection Phase

[0064] Execute the instrumented program executable file to generate an event log file. Then read the log file and sort all events in chronological order from small to large. The resulting sequence is the event sequence, which includes three types of events: branch jump, function entry, and function exit.

[0065] 3. Control flow inconsistency detection phase

[0066] 1. Restore the control flow information during program execution based on the event sequence, namely the function stack status and the control flow path selection status within the function.

[0067] First, scan the time series sequentially, and restore the function stack status ρ(e) for each event e according to the relative order of function entry and function exit events in the sequence. Here, a function stack sequence [F1, F2, …, F n ] to represent the function stack status of event e, where each element F i Indicates a function that has been entered but not yet exited. F1 is the function at the bottom of the function stack. n The function at the top of the function stack. The function stack sequence is initially empty and is gradually updated as the events in the event sequence are scanned. When the scan proceeds to event e (the function stack sequence is not updated according to event e), the function stack sequence at this time represents the function stack status at event e. The function stack sequence update method refers to when the scan advances to event e, if event e is a branch jump event, the function stack sequence is not updated; if event e is a function entry event, the function F it enters is added to the end of the function stack sequence; if event e is a function exit event, the function F it exits is removed from the end of the function stack sequence.

[0068] According to the function stack status ρ(e), the event sequence is divided into a series of continuous event sequence fragments, forming an event sequence fragment sequence T = [S1, S2, ..., S n ], where each element S i Represents an event sequence fragment, which includes a series of consecutive events with the same function stack status, that is, S i =[e k ,e k+1 ,…,e l ], where e k ,e k+1 ,…,e l appear continuously in the event sequence and have the same function stack status, that is, ρ(e k )=ρ(e k+1 )=…=ρ(e l ).

[0069] 2. Then compare and analyze the control flow information before and after the program is transplanted to check whether there is any control flow inconsistency during the cross-platform transplantation process.

[0070] Comparative analysis of event sequence fragments before and after cross-platform transplantation, represented by T = [S1, S2, ..., S n ] and T′=[S′1,S′2,…,S′ m ], and sequentially compare the function stack status and the control flow path selection status within the function of the event sequence fragments at the corresponding positions in the two event sequence fragment sequences to see whether they are the same. The specific comparison method is as follows:

[0071] (1) First, compare S1 and S′1 to see if they are the same in terms of function stack status and control flow path selection status within the function; when comparing S i With S′ j When comparing the function stack status, first compare whether they are the same, and then compare whether the control flow path selection status within the function is the same;

[0072] (2) If S i With S′ j If the function stack status is different, it will report that the target program to be tested has inconsistent control flow and suspend the inconsistency check. Later, it is necessary to try to perform error rollback to resume the inconsistency check;

[0073] (3) If S i With S′ jIf the function stack status is the same, but the control flow path selection status within the function is different, further inspection is required to determine whether the difference is serious enough to cause control flow inconsistency. If the difference is serious enough and will cause control flow inconsistency, the inconsistency is reported and the inconsistency check is suspended. Later, an error rollback is attempted to resume the inconsistency check. Otherwise, if the difference does not cause control flow inconsistency, continue to compare S i+1 With S′ j+1 ;

[0074] (4) If S i Is it related to S′ j The function stack status and the control flow path selection status within the function are the same, then it is considered that S i With S′ j There is no cross-platform control flow inconsistency, and continue to compare S i+1 With S′ j+1 ;

[0075] (5) When this comparison reaches the end of one of the fragment sequences, fragment S i+1 or S′ j+1 Does not exist, inconsistency check ends.

[0076] The comparison of the control flow path selection status within the function in the above step (1) adopts an inconsistency detection method, including the following steps:

[0077] (1) Sequential traversal of S i and S′ j All branch jump events in are denoted as σ(S i )=[e1,e2,…,e n ] and σ(S′ j )=[e′1,e′2,…,e′ m ], compare e one by one i and e′ j Whether the jump type and jump condition are the same;

[0078] (2) First, compare whether e1 and e′1 are completely identical in terms of jump type and jump condition;

[0079] (3) If e i and e′ j If there is any difference in jump type or jump condition, it is determined that there is a difference in the control flow path selection status within the function that can cause control flow inconsistency, and the inconsistency is reported and the inconsistency check is suspended;

[0080] (4) If e i and e′ j If the jump type or jump condition is exactly the same, then continue to compare e i+1 and e′ j+1;

[0081] (5) When this comparison reaches the end of one of the sequences, event e i+1 or e′ j+1 does not exist, and no difference in the event jump type or jump condition is found, then the tested event segment S i and S′ j There are not enough differences in the control flow path selection within the function to cause control flow inconsistency.

[0082] In the above steps, when a control flow inconsistency is detected, a certain method is used to try to eliminate the impact of the control flow inconsistency in the subsequent sequence segments and resume the inconsistency check. If the recovery is successful, the inconsistency check continues, otherwise the check is terminated.

[0083] If the inconsistency check method is used in the event sequence fragment sequence T = [S1, S2, ..., S n ] and T′=[S′1,S′2,…,S′ m ] in the sequence fragment S i and S′ j The control flow inconsistency is detected, and ρ(S i )=[F1,F2,…,F m ],ρ(S′ j )=[F′1,F′2,…,F′ n ], then find a ρ(S i ) and ρ(S′ j )'s longest common prefix sequence satisfy And so on. Then:

[0084] (1) If the longest common prefix sequence is empty, that is, κ(S i ,S′ j )=[], the influence of control flow inconsistency cannot be eliminated, so the inconsistency check ends;

[0085] (2) If the longest common prefix sequence is not empty, scan T one by one and then find the longest common prefix sequence in S. i Sequence fragments, find the first fragment S p So that ρ(S p )=κ(S i ,S′ j ); After scanning one by one in T′, j Sequence fragments, find the first fragment S′ q So that ρ(S′ q )=κ(S i ,S′ j ). If the condition S is metp or S′ q If S does not exist, the influence of control flow inconsistency cannot be eliminated, so the inconsistency check is terminated. Otherwise, check S according to the method as claimed in claim 4. p and S′ q Whether there are control flow inconsistencies;

[0086] (3) If S p and S′ q There is still a control flow inconsistency, so let S i =S p and S′j=S′q and repeat the above steps;

[0087] (4) If S p and S′ q If there is no control flow inconsistency, the impact of the control flow inconsistency has been eliminated, and the inconsistency check is resumed and the process continues in S p+1 and S′ q+1 The aforementioned control flow inconsistency checking method is executed on the controller.

[0088] 4. Report Generation Phase

[0089] In this phase, based on the control flow inconsistency position obtained through analysis, relevant information is extracted from the source code position information data corresponding to the control flow point recorded in phase 1 and presented in the report. The report reports the program running commands required to trigger the control flow inconsistency, the function call chain at the inconsistency point, and the source code lines involved.

[0090] Another embodiment of the present invention further discloses a control flow consistency verification system before and after program cross-platform migration, which is used to implement the above method. The system includes a source code plug-in module, a sequence collection module, a control flow inconsistency verification module and a report generation module. The main functions of the four modules are as follows:

[0091] Source code instrumentation module: responsible for instrumenting the source code of the target program to be tested. The instrumentation code is responsible for recording branch jump events, function entry events, and function exit events. On the platforms before and after the program is transplanted across platforms, the instrumented executable files are generated, as well as an information database that records the source code location corresponding to each instrumentation point.

[0092] Sequence generation module: responsible for running the instrumented executable file to obtain the event sequence.

[0093] Control flow inconsistency detection module: Analyze and restore the control flow information of the program when it is running according to the event sequence, and then compare the control flow information of the program before and after the transplantation to identify control flow inconsistencies.

[0094] Report generation module: responsible for extracting relevant information from the source code location information database generated by the source code instrumentation module based on the detected control flow inconsistency, and generating a control flow inconsistency detection report containing debugging information such as inconsistent related code file paths, source code lines, variable symbol names, etc.

[0095] Another embodiment of the present invention provides a computer-readable storage medium (such as ROM / RAM, magnetic disk, optical disk), wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a computer, the steps of the method of the present invention are implemented.

[0096] The above embodiments are provided only for the purpose of describing the present invention, and are not intended to limit the scope of protection of the present invention. The scope of protection of the present invention is defined by the claims. Various equivalent substitutions and modifications made without departing from the spirit and principle of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for checking control flow consistency before and after program cross-platform migration, characterized in that: The following steps are involved: 1) On the platforms before and after the cross-platform transplantation, compile the target program source code to be tested and perform stub insertion, generate the program executable file after stub insertion, and record the source code location information corresponding to each stub insertion point; 2) Execute the program executable file after the instrumentation to obtain the event sequence; 3) Scan and analyze the event sequence to restore the runtime control flow information of the target program to be tested before and after the cross-platform transplantation, including the function stack status and the control flow path selection status within the function; 4) Compare and analyze the control flow information before and after cross-platform transplantation to check whether there is any control flow inconsistency in the target program to be tested; 5) If there is a control flow inconsistency, the code position where the control flow inconsistency occurs is located in the source code according to the recorded source code position information, and a control flow inconsistency report is generated.

2. The method according to claim 1, characterized in that The event sequence in step 1) includes: branch jump event, function entry event and function exit event, and the source code location information includes the file path, code line number and variable symbol name information of the source code.

3. The method according to claim 2, characterized in that In step 1), when compiling the source code of the target program to be tested, inserting stub code at each control flow jump of the program to record control branch events, inserting stub code at the entry and exit of the function, and recording function entry and function exit events; For branch jump events, the jump type and the jump condition variable value are recorded; for function entry events and function exit events, the entered function and the exited function are recorded accordingly.

4. The method according to claim 1, characterized in that In step 2), the program executable file after the instrumentation is executed to generate a record file of events; the record file is read, and all events are sorted in chronological order from small to large to obtain an event sequence.

5. The method according to claim 1, characterized in that The steps of restoring the control flow information at runtime in step 3) include: Scan the event sequence sequentially and calculate the function stack status of each event; According to the function stack status information of the event, the event sequence is divided into a plurality of event sequence segments, each event sequence segment includes a series of events that are continuous in the event sequence and have the same function stack status; Sequentially scan the branch jump information in each event sequence fragment to restore the control flow path selection status within the function.

6. The method according to claim 5, characterized in that The steps to calculate the function stack status for each event include: Maintain a function stack sequence to represent the function stack status of the program at the time point of the event. Each element in the function stack sequence represents a function that has been entered but not yet exited; The function stack sequence is initially empty and is gradually updated as the events in the event sequence are scanned. The updating method is as follows: when the scan advances to an event, if the event is a branch jump event, the function stack sequence is not updated; if the event is a function entry event, the entered function is added to the end of the function stack sequence; if the event is a function exit event, the exited function is removed from the end of the function stack sequence; when the scan reaches the event, the function stack sequence at this time is the function stack status of the event.

7. The method according to claim 1, characterized in that The step of checking whether the target program to be tested has control flow inconsistency in step 4) includes: For the two event sequence fragment sequences before and after the cross-platform transplantation, firstly, the function stack states of the two event sequence fragments at the corresponding positions in the two event sequence fragment sequences are compared to see whether they are the same, and then the control flow path selection states in the functions are compared to see whether they are the same; If the function stack states of the two event sequence fragments are different, a control flow inconsistency is reported in the target program to be tested, and the inconsistency check is suspended, and then an error rollback is attempted to resume the inconsistency check; If the function stack conditions of the two event sequence fragments are the same, but there are differences in the control flow path selection conditions within the function, then further check the degree of the difference; if the difference causes control flow inconsistency, then report the inconsistency and suspend the inconsistency check, and then try error rollback to resume the inconsistency check; if the difference does not cause control flow inconsistency, then continue to compare the next pair of event sequence fragments; If the function stack status and the control flow path selection status within the function of the two event sequence fragments are the same, it is considered that there is no cross-platform control flow inconsistency between the two event sequence fragments, and the next pair of event sequence fragments are compared; When the above comparison reaches the end of one of the event sequences, the inconsistency check ends.

8. The method according to claim 7, characterized in that The steps of comparing whether the control flow path selection conditions in the function are the same include: Sequentially traverse all branch jump events in the two event sequence segments, first compare whether two branch jump events at corresponding positions in the two event sequence segments are completely identical in jump type and jump condition; If the two branch jump events are different in jump type or jump condition, it is determined that there is a difference in the control flow path selection status within the function that causes the control flow inconsistency, the inconsistency is reported and the inconsistency check is suspended; If the two branch jump events are completely identical in jump type and jump condition, then continue to compare the next pair of branch jump events; When the comparison reaches the end of one of the event sequences, if no difference is found in the jump type or jump condition between the events, it is considered that there is no difference in the control flow path selection status within the function between the two event fragments that causes inconsistent control flow.

9. The method according to claim 8, characterized in that When a difference is detected, an inconsistency is reported and the inconsistency check is suspended, the following steps are performed to eliminate the impact of the inconsistency in subsequent sequence segments and resume the inconsistency check: If control flow inconsistency is detected between the two event sequence segments, finding a longest common prefix sequence in the function stack states of the two event sequence segments; If the longest common prefix sequence is empty, the inconsistency check ends; If the longest common prefix sequence is not empty, the subsequent event sequence segments are sequentially scanned one by one in the two event sequence segment sequences to find the first event sequence segment S that meets the condition equal to the longest common prefix sequence. q and S′ q ; If the condition S is met p or S′ p If it does not exist, then end the inconsistency check, otherwise check S p and S′ q Whether there are control flow inconsistencies; If S p and S′ q If there is a control flow inconsistency, repeat the above steps; If S p and S′ q If there is no control flow inconsistency, resume the inconsistency check and continue with the second event sequence fragment S that satisfies the condition equal to the longest common prefix sequence. p+1 and S′ q+1 Perform control flow inconsistency checking on the 10. A control flow consistency verification system before and after program cross-platform migration, used to implement the method according to any one of claims 1 to 9, characterized in that: include: The program instrumentation module is used to compile the target program source code and perform instrumentation on the platforms before and after cross-platform transplantation, generate the program executable file after instrumentation, and record the source code location information corresponding to each instrumentation point; The sequence collection module is used to execute the program executable file after the instrumentation to obtain the event sequence; The control flow consistency check module is used to scan and analyze the event sequence, and restore the runtime control flow information of the target program to be tested before and after the cross-platform transplantation. The control flow information includes the function stack status and the control flow path selection status within the function; Compare and analyze the control flow information before and after cross-platform migration to check whether there is any control flow inconsistency in the target program to be tested; The report generation module is used to locate the code position where the control flow inconsistency occurs in the source code according to the recorded source code position information when a control flow inconsistency is detected, and to generate a control flow inconsistency report.