Automatic Repair Tool

Scenario in Which the Automatic Repair Tool Is Not Used

1. (Optional) Download the GCC source code of the required version from the GCC official website. This practice uses the GCC 9.3.0 source package to compile and set GCC environment variables, as shown in Figure 1.
   Figure 1 Setting GCC environment variables
   
   

   For details about the compilation process, see related documents on the GCC official website.

2. Use the installed GCC 9.3.0 to compile and generate the executable file for 20,000 times. See Figure 2.
   1. Decompress the source package and check the file content.

      1 2	tar -zxvf fifo.tar.gz ls

   2. Compile the source code.

      1

      make

   3. Run the generated executable file.

      1	./one_producer_one_consumer

   

   In the source code is a lock-free queue with a single producer and a single consumer. The producer inputs the data 1, 2, and 3 (int type) to the queue in sequence. The consumer reads the data from the queue and assigns values to the variables r1, r2, and r3 (int type). The expected result is r1=1, r2=2, and r3=3 if no memory inconsistency error occurs.

   Figure 2 Reproducing memory inconsistency issues
   

   Result: Memory inconsistency issue occurred for 12 times in 20,000 tests.

Scenario in Which the Automatic Repair Tool Is Used

1. Install the memory inconsistency repair component.
   1. Obtain the memory inconsistency repair component.

      Obtain /opt/DevKit/devkitplugins/affinity/tools/weakconsistency/gccchecker/gcctool.tar.gz in the DevKit installation directory.

      

      /opt/DevKit is the tool installation directory. Replace it with the actual directory.

   2. Decompress the installation package.

      1	tar xf gcctool.tar.gz

      Check that the gcctool, gcctool-bin, and libstdc++.so.6 files exist in the gcctool/bin directory.

   3. Set environment variables.

      Save the gcctool file in a user-defined directory and set export PATH=/path/to/gcctool/bin:$PATH.

      

      /path/to indicates the user-defined directory for storing gcctool.

2. Download and decompress the GCC source package of the corresponding version from the GCC official website. This practice uses the GCC 9.3 source package.

   Obtain the GCC repair tool patch (for Debian and Red Hat).

   1	tar -xvf gcc-9.3.0.tar.gz

3. Run the following command to apply the GCC patch. See Figure 3.

   cd gcc-9.3.0/
   patch -p1 < /path/to/gcc-9.3.0.patch

   Figure 3 Applying the GCC 9.3 patch
   
4. Compile GCC and set GCC environment variables, as shown in Figure 4.
   

   • For details about the compilation process, see related documents on the GCC official website.
   • Set the paths based on your actual situation when configuring environment variables.
   Figure 4 Setting environment variables
   
5. Compile the FIFO source code.

   Go to the FIFO source code directory and set the optimization level of the memory inconsistency repair component to export HW_DEBUG=[ 0 | 1 | 2 ]. In this practice, set the optimization level to 1 and run the make command for compilation.

   1 2 3

   export HW_DEBUG=1 make clean make

   After the compilation is complete, run the following command:

   1	objdump -d one_producer_one_consumer | grep dmb | head -20

   The locations of the 20 inconsistency issues that have been repaired are displayed. See Figure 5.

   The compiling component supports configuration of the optimization level through environment variables. If the environment variables are not set, the repair tool does not take effect.

   Figure 5 Taking effect of the repair tool
   
   

   export HW_DEBUG=[ 0 | 1 | 2 ]

   • 0: Do not use any optimization policy. This setting results in the largest performance loss.
   • 1: Use the most secure repair policy. This setting compromises the performance a lot.
   • 2: Use component optimization rules. This setting helps minimize the performance loss.
6. Verify the source code repair result.
   Run the following command in the source code directory:

   1	./one_producer_one_consumer

   Perform the test for 20,000 consecutive times in the executable file. The result shows that no memory inconsistency exception occurs, so the repair tool takes effect. See Figure 6.

   Figure 6 Taking effect of the automatic repair tool
   

Verification Conclusion of the Automatic Repair Tool

When the repair tool is not used in the FIFO source code, 20,000 tests are performed, among which 12 tests are abnormal. After the repair tool is used, 20,000 memory barrier instructions are inserted and 20,000 tests are performed. No exception occurs.