Rate This Document
Findability
Accuracy
Completeness
Readability

Source Code Scanning in Lock Protection Scenarios

The memory consistency check of shared variables in lock protection scenarios is based on Source Code Scans in Common Scenarios. When shared variables are completely protected by locks, the mutex analysis module of the static scan tool filters out the shared variables. Therefore, the final report does not contain the statements related to the shared variables.

Scanning the Source Code

  1. Download the sample code lock from GitHub or Gitee to obtain the software source package. View the source code on the server. See Figure 1.

    The downloaded source package is devkitdemo-main.zip. The ./devkitdemo-main/Porting_advisor/testdemo/weak_consistency/lock file extracted from the package is the code to be scanned for static memory consistency check.

    Figure 1 Source code file lock.c
  2. Generate a BC file.
    1. Scan the updated source file and generate a BC file.
      1
      2
      cd /home/software/Porting_advisor/testdemo/weak_consistency/lock/
      devkit advisor bc-gen -o /home/report -c make
      

      Command output:

      Executing bc gen task, please wait...
      Current progress: ###### [20%]
      Start to get the compile database
      Current progress: ################ [50%]
      Start to generate the BC files
      Current progress: ################################# [100%]
      Configuration:
          Generate BC files path: /home/report
          Compile command: make
          Threads: The threads is not set, using the half number of cores.
          Task Timeout Interval: The timeout period is not set.
          Log level: info
      
      Summary:
          Scanned all source files, there are 1 linked BC files and 1 object BC files generated.
      
      For the detail information, please check:
      Output path of linked BC files: /home/report/bc-gen_20250526023145_9aa4/bin
      Output path of object BC files: /home/report/bc-gen_20250526023145_9aa4/object
      
      There are 0 linked BC files fail to be generated. For the causes of the failure to generate all the BC files and their intermediates, please check:
      Log path: /opt/DevKit-CLI-x.x.x-Linux-Kunpeng/advisor/logs/affinity/affinity.log
      • -o: Path for storing the generated BC file. You must have the write permission on the path. By default, the report is saved in the current path and is named in the format of Module name_Timestamp.
      • -c: Builds source code.

      Download the bc-gen_20250526023145_9aa4 folder in the path next to Output path of linked BC files in the command output. The bin folder is used to store the BC file in 3.

  3. Log in to the Kunpeng DevKit. In the navigation tree, choose Affinity Analyzer > Static Memory Consistency Check. Set Check Mode to Static check.

    Click Select Folder next to Source File Path and upload the lock folder. Click Select Folder next to BC File Path and upload the bin folder. See Figure 2.

    Figure 2 Memory consistency static check
  4. Click Check to check the memory consistency. A check report is displayed. See Figure 3.
    Figure 3 Check report

    lock.c is the source code file for the memory consistency check of shared variables that are protected by locks. Based on Source Code Scans in Common Scenarios, when the shared variables are completely protected by locks, the mutex analysis module of the static scan tool filters out the shared variables. Therefore, the final report does not contain the statements related to the shared variables. That is, the memory consistency check does not identify any content to be modified, and no memory inconsistency issue exists in the source code.