Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake: add LLVM coverage support #8376

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

altimeter-130ft
Copy link

@altimeter-130ft altimeter-130ft commented Jan 14, 2024

This PR adds the coverage support to the platform with the LLVM/clang only, without GCC.

Background
This change is essential for FreeBSD as the Fluent Bit development platform. The master branch as of f8bd0ce does not build on FreeBSD 14.0-RELEASE because of the strerror_r(3) signature dependency on glibc. I am addressing this issue in parallel, in which the code coverage is required to prove the fix.

New CMake Build Option(s)

  • FLB_COVERAGE_TYPE
    • Configure the coverage type.
      • gcov: (default) gcov; native for GCC, compatible with LLVM/clang.
      • llvm: LLVM; native for LLVM/clang.
    • FLB_COVERAGE is required.

Change(s) to CMAKE_C_FLAGS

  • Add -fprofile-instr-generate -fcoverage-mapping.
    These are the standard CFLAGS options to enable the code coverage profile instrumentation on LLVM/clang.

Change(s) to Test Execution Environment

  • Add LLVM_PROFILE_FILE=${CMAKE_CURRENT_BINARY_DIR}/(testname).profraw.
    • Output the raw profile data to the file distinct for each test.
    • Limitation: A runtime_shell test can execute at most one test binary.

Out of Scope

  • Collect the raw profile data files into a single profile data file by llvm-profdata.
  • Generate the reports by llvm-cov.

Tested Environment

  • Debian x86_64 12.2
    • Debian clang version 14.0.6

Testing
Before we can approve your change; please submit the following in a comment:

  • N/A Example configuration file for the change
    This change does not add any new features to the Fluent Bit binary.
  • Debug log output from testing the change
    • logs-fluent-bit-topic-llvm-coverage.zip: The archive of the log files and sample LLVM coverage report.
      • logs-fluent-bit-topic-llvm-coverage/
        • fluent-bit-cmake-topic-llvm-coverage-debian_x86_64_12_2.log: The cmake log.
          • Command line: env CC=clang-14 CXX=clang++-14 CPP=clang-cpp-14 LD=ld.lld RANLIB=llvm-ranlib-14 cmake -DFLB_COVERAGE=true -DFLB_COVERAGE_TYPE=llvm -DFLB_DEV=true -DFLB_VALGRIND=true -DFLB_TESTS_RUNTIME=true ..
        • fluent-bit-make-topic-llvm-coverage-debian_x86_64_12_2.log: The make log.
          • Command line: env CC=clang-14 CXX=clang++-14 CPP=clang-cpp-14 LD=ld.lld RANLIB=llvm-ranlib-14 make
        • fluent-bit-ctest-topic-llvm-coverage-debian_x86_64_12_2.log: The ctest log.
          • Command line: ctest
          • Remarks:
            • 1 failure.
              • flb-rt-out_td: The test environment problem, I cannot make the valid test configuration.
            • 2 cases stopped manually by SIGTERM.
              • in_syslog_uds_dgram_plaintext_expect.sh, in_syslog_uds_stream_plaintext_expect.sh: These are known to stall for more than 5 minutes, found during the test rehearsal. The results after SIGTERM are both successful.
        • fluent-bit-find-profraw-topic-llvm-coverage-debian_x86_64_12_2.log: The LLVM profile files found after ctest.
          • Command line: find tests -type f -name '*.profraw'
        • fluent-bit-llvm-profdata-cov-topic-llvm-coverage-debian_x86_64_12_2.log: The LLVM profile data collection and coverage report generation.
          • Command line: Please refer to the log file.
        • llvm-cov-test-topic-llvm-coverage-debian_x86_64_12_2.tar.xz: The LLVM coverage report in HTML.
  • N/A Attached Valgrind output that shows no leaks or memory corruption was found
    This change does not touch any C sources.

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

This change does not touch the packaging.

Documentation

Backporting


Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

If FLB_COVERAGE is on, FLB_COVERAGE_TYPE can be configured for the coverage
type, which is one of:

- gcov (default)
- llvm

Signed-off-by: Seigo Tanimura <[email protected]>
This allows llvm-profdata(1) to collect the test execution profiles.

Signed-off-by: Seigo Tanimura <[email protected]>
@edsiper
Copy link
Member

edsiper commented Jan 17, 2024

Hi, I know little about this but how the coverage stuff helps to get this build on BSD?

@altimeter-130ft
Copy link
Author

Hi, I know little about this but how the coverage stuff helps to get this build on BSD?

My ultimate goal is to address the build breakage on FreeBSD due to the use of strerror_r(3) by a wrapper function on it. Please refer to #8379 for the detail.

The wrapper function of strerror_r(3) requires a new test case for the verification, including the coverage check of the test case. After implementing the strerror_r(3) fix, I found that Fluent Bit supports the gcov coverage only. This is not native on FreeBSD now because it has replaced GCC by LLVM/clang since 10.0-RELEASE.

Although LLVM can emit the gcov coverage data somehow, that is merely a compatibility feature. It is better to support the LLVM-native coverage support to minimize the build prerequisites, as well as to avoid any problems that may happen in the compatibility feature only.

The coverage part has been separated from the main fix because they change the different modules in Fluent Bit; the former changes the build system (hence tagged by cmake), while the latter works on the sources under src and tests.

The main strerror_r(3) fix is in the separate branch. This will be submitted as a separate PR soon.

Copy link
Contributor

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Apr 19, 2024
@github-actions github-actions bot removed the Stale label Aug 16, 2024
Copy link
Contributor

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants