Static Memory Consistency Check
The tool checks for any memory consistency problem when the source code is ported to the Kunpeng platform and provides suggestions on inserting memory barriers.
- During a static memory consistency check, a large number of intermediate files are generated. If you want to use this function, ensure an enough drive space. Generally, about 100 GB drive space is required for every 100,000 lines of code.
- The check of a large amount of source code consumes many resources. It is recommended the code to be checked do not exceed 100,000 lines.
- The static memory consistency check function is available on the Kunpeng platform.
Prerequisites
- /opt/DevKit is the default installation directory of the tool. The following uses this directory as an example. Replace it with the actual directory.
- To perform a 64-bit running mode check on the WebUI, you need to manually upload files or compressed packages. In the IDE, you can simply scan local projects to run the check.
Procedure
- On the left pane of the page, choose Affinity Analyzer > Static Memory Consistency Check, and click
to create a task. See Figure 1. - Select a check mode.
- Static check
- Auto repair by compiler. For details, see Using the Auto Repair by Compiler.
The static check features low false positive ratio and a repair rate up to 60%. The auto repair by compiler does not miss any report and features a repair rate of 100%, but the false positive ratio is higher. Higher false positive ratio indicates greater impact on performance. The repair rate varies depending on the software, and the impact on performance also varies.
- Set Source file path using either of the following methods:
- If you want to use uploaded source code, click the text box and select a source code path from the drop-down list or manually enter a source code path.
- Click Upload on the right to upload the package or folder. (The package is automatically decompressed during the upload.)
- Only TAR, TAR.BZ, TAR.BZ2, TAR.GZ, TAR.XZ, TBZ, TBZ2, TGZ, TXZ and ZIP packages can be uploaded. Only one package can be uploaded at a time. The source package cannot exceed 1 GB, and the extracted files must be less than or equal to half of the remaining drive space.
- Only one folder can be uploaded at a time. The size of the folder must be less than or equal to half of the remaining drive space.
- Set BC File Path using either of the following methods:
- If you want to use an uploaded BC file, click the text box and select a BC path from the drop-down list or manually enter a BC path.
- Click Upload on the right to upload the package or folder. (The package is automatically decompressed during the upload.)
- For details about the BC file and how to obtain it, see Generating a BC File.
- Only TAR, TAR.BZ, TAR.BZ2, TAR.GZ, TAR.XZ, TBZ, TBZ2, TGZ, TXZ and ZIP packages can be uploaded. Only one package can be uploaded at a time. The source package cannot exceed 1 GB, and the extracted files must be less than or equal to half of the remaining drive space.
- Only one folder can be uploaded at a time. The size of the folder must be less than or equal to half of the remaining drive space.
- Choose whether to generate a compiler configuration file. The default value is Disabled.
- Click Check to start the static memory consistency check. After the check is complete, the check report page is displayed. See Figure 2.
- You can click
to sort the source files to be modified by path or number of recommended modifications. - You can click Download Report (.csv) or Download Report (.html) to download the report to your local PC.
- If Generating compiler tool configuration files is selected, you can click Download compiler configuration files to download the file. You can also hover the mouse pointer over the
of the target report in the Historical Reports area and select Download compiler configuration files. - If the system displays a message indicating that the compiler file is not the latest, click Go to download the file from the latest report. If the system displays a message indicating that the latest report does not contain the compiler configuration file, perform operations as prompted.
- You can click
- Click View Suggested Source Code. The Source Code Modification Suggestion tab page is displayed. See Figure 3.
- The tool supports concurrent running of multiple static memory consistency check tasks.
- To cancel a task, click Close during the task running process.
- You can click the arrow keys in the upper right corner of Original Source Code to view the code.
- If you use shortcut keys to modify the source code, pay attention to shortcut key conflicts caused by the input method or IDE environment.
- If the check fails or the check result indicates that no modification is required, an empty report is generated.
- If the system displays a message indicating that the task times out, rectify the fault by following instructions in Task Timed Out.
Using the Auto Repair by Compiler
Table 1 lists the OSs and GCC versions supported by the tool.
|
OS |
GCC Version |
|---|---|
|
BC-Linux 7.6/7.7 |
GCC 4.8.5/4.9.3/5.1.0/5.2.0/5.3.0/5.4.0/5.5.0/6.1.0/6.2.0/6.3.0/6.4.0/6.5.0/7.1.0/7.2.0/7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
CentOS 7.4/7.5/7.6/7.7 |
GCC 4.8.5/4.9.3/5.1.0/5.2.0/5.3.0/5.4.0/5.5.0/6.1.0/6.2.0/6.3.0/6.4.0/6.5.0/7.1.0/7.2.0/7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
CentOS 8.0 |
GCC 8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
CentOS 8.1/8.2 |
GCC 8.3.0/9.1.0/9.2.0/9.3.0 |
|
Debian 10 |
GCC 8.3.0/9.1.0/9.2.0/9.3.0 |
|
Deepin 15.2 |
GCC 6.3.0/6.4.0/6.5.0/7.1.0/7.2.0/7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
iSoft 5.1 |
GCC 7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
Kylin V10 SP1/SP2 |
GCC 7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
LinxOS 6.0.90 |
GCC 6.3.0/6.4.0/6.5.0/7.1.0/7.2.0/7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
NeoKylin V7U6 |
GCC 4.8.5/4.9.3/5.1.0/5.2.0/5.3.0/5.4.0/5.5.0/6.1.0/6.2.0/6.3.0/6.4.0/6.5.0/7.1.0/7.2.0/7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
openEuler 20.03/LTS SP1/LTS SP2/LTS SP3 |
GCC 7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
SUSE SLES15.1 |
GCC 7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
Ubuntu 18.04.x |
GCC 7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
Ubuntu 20.04.x |
GCC 9.3.0 |
|
UOS 20 SP1 |
GCC 8.3.0/9.1.0/9.2.0/9.3.0 |
|
uosEuler 20 |
GCC 7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
|
UOS 20-1020e |
GCC 7.3.0/7.4.0/8.1.0/8.2.0/8.3.0/9.1.0/9.2.0/9.3.0 |
- The GCC versions listed are the default GCC versions supported by the OSs. If the GCC version of the server has been upgraded, compatibility issues may occur.
- The supported GCC versions are official GCC branches. Do not use the GCC for openEuler versions.
Before using this function, you need to configure the environment as follows:
- Download required software packages.
- GCC source code: https://gcc.gnu.org/ (Download the source code of the corresponding version from the official GCC website.)
- GCC repair tool patch: https://github.com/kunpengcompute/devkitdriver/tree/main/gccchecker (for Debian and RHEL OSs)
- Memory consistency repair component: Obtain /devkitplugins/affinity/tools/weakconsistency/gccchecker/gcctool.tar.gz in the DevKit installation directory.
- Install the memory consistency repair component.
- Decompress the installation package.
1tar xf gcctool.tar.gz
After the decompression, check that the following files exist in the gcctool/bin directory:
gcctool, gcctool-bin, and libstdc++.so.6
- Decompress the installation package.
- Apply the GCC patch.
If "'patch' command not found" is displayed, run the following command to install the patch:
Debian OSs:
1apt install patch
RHEL OSs:
1yum install patch
1 2
cd /gcc/source/root/dir patch -p1 < /path/to/gcc/patch/file
- Compile GCC.
For details about how to compile the GCC source code, see the official GCC documents. The patch does not affect the GCC dependency components and the compilation process. If you have any GCC compilation problem, visit the GNU community.
After the environment is set up, perform the following steps to use the tool:
- Set the optimization level of the memory consistency repair component.
1export HW_DEBUG=[ 0 | 1 | 2 ]
You can set the repair optimization level through an environment variable. The default level is 0.
- 0: disables the memory consistency repair function.
- 1: uses component optimization rules. This setting helps minimize the performance loss.
- 2: uses the most secure repair policy. This setting compromises the performance a lot.
- (Optional) Define the range of source code that can be automatically fixed.
- You can customize the source code repair range by file or function. After the allowlist is configured, the repair component repairs only the content in the list. The allowlist must meet the following requirements:
- The file list starts with files:. Each file occupies one line.
- The file path must be an absolute path.
- Only C, C++, and Fortran files are supported. Pure assembly files are not supported.
- The function list starts with functions:. Each function occupies one line.
- C/C++ common functions are supported. Templates or functions with the abi_tag attribute are not supported.
Allowlist example:
1 2 3 4 5 6 7 8 9 10 11 12 13
files: /path/to/file/a /path/to/./file/b /path/to/../file/c /path/to/file/d functions: func_a func_b() func_c(int xxx) int func_d() classA::func_e ns::classB::func_f() std::string nsA::nsB::classC::func_g(int xxx)
- The repair component obtains the path of the allowlist.
You can set environment variables to specify the path of the allowlist. The path is not specified by default.
export AUTOFIXLIST=/path/to/allowlist
- You can customize the source code repair range by file or function. After the allowlist is configured, the repair component repairs only the content in the list. The allowlist must meet the following requirements:
- Compile software.
The compilation process remains unchanged.
Remove the -pipe compilation option if it is used in the previous compilation. This does not affect the result of the previous compilation.


