W-M-R opened a new pull request, #21344:
URL: https://github.com/apache/nuttx/pull/21344

   ## Summary
   
   `tools/gcov.py` only handled the GCC coverage flow: it drove `gcov` + `lcov`
   + `genhtml` and assumed the user picks the toolchain by hand. Clang's
   source-based coverage (`profraw` / `__llvm_covmap`) was not supported at all,
   and the two toolchains produced differently-shaped reports.
   
   This change brings `tools/gcov.py` to feature parity between both toolchains:
   
   - Add the clang pipeline: `llvm-profdata merge` + `llvm-cov 
export/show/report`,
     with `llvm-profdata`, `llvm-cov`, `llvm-readelf` and `ld.lld` discovered
     next to the toolchain selected by the user.
   - Detect the toolchain from the firmware ELF instead of asking the user:
     clang vs gcc from `.comment`, target arch from `e_machine`, using a small
     pure-Python ELF inspector (no external `readelf`).
   - Build a relocatable object from the `.o` files carrying `__llvm_covmap`
     sections, to work around the `VMA=0` layout of lld-linked ELFs.
   - Route both toolchains through one representation: GCC captures an lcov
     tracefile with `lcov -c`, clang exports the same format with
     `llvm-cov export -format=lcov`, and `genhtml` renders both, so reports look
     identical and tracefiles can be merged with `lcov --add-tracefile`.
     `--llvm-html` keeps the region-level `llvm-cov show` output as an option.
   - Accept both native and byte-swapped LLVM raw-profile magic so `profraw`
     dumps from little-endian targets (aarch64, x86_64, sim) are classified
     correctly instead of being fed to the text parser.
   - Parse gcov binary pack files produced by `gcov_binfile_dump`
     (`COVERAGE_MINI` mode), and skip `genhtml` when the lcov tracefile has no
     `SF:` records (toolchain version mismatch) instead of failing.
   - Keep `.gcda` files present in only one `-a` input during merge, add TriCore
     `tricore-elf-gcov` discovery, and reduce log noise.
   
   ## Impact
   
   - Tools only: `tools/gcov.py` is the single file touched, no kernel, driver 
or
     board code changes.
   - CLI change: `-e/--elf` is now required and is the source of truth for the
     toolchain; `-t` and `--toolchain` are gone; `-s` is optional for clang;
     `--llvm-html`, `--debug` and `--delete` are unchanged in spirit.
     Existing gcc-only invocations must pass `-e <nuttx elf>`.
   - Clang coverage requires `llvm-profdata` / `llvm-cov` / `llvm-readelf` /
     `ld.lld` available under the same prefix as the cross toolchain.
   - `lcov` version differences are handled: the `--ignore-errors` value is
     selected according to the detected lcov version (1.x vs 2.x).
   - No impact on build system, hardware, documentation or security.
   - Depends on nothing outside this tree.
   
   ## Testing
   
   Host: Ubuntu 22.04 x86_64, Python 3.10, `lcov` 1.16 and 2.x, LLVM 18/21.
   
   Performed on this branch:
   
   1. Static check of the script:
   
      $ python3 -m py_compile tools/gcov.py
      $ echo $?
      0
   
   2. CLI smoke test (argparse wiring, required `-e` enforced):
   
      $ python3 tools/gcov.py
      usage: gcov.py -h -e ELF_BINARY -s GCNO_DIR [-a DATA_INPUTS DATA_INPUTS 
...]
                     -o RESULT_DIR -b OLD=NEW --llvm-html --debug --delete
      gcov.py: error: the following arguments are required: -e/--elf
   
   3. Verified the resulting file matches the source-of-truth implementation
   byte for byte (`tools/gcov.py`, 1451 lines).
   
   End-to-end runs (please attach the logs):
   
   - GCC path, `mps3-an547:gcov` configuration:
   
     $ ./tools/configure.sh -l mps3-an547:gcov && make -j$(nproc)
     $ ./tools/gcov.py -e nuttx -s <gcno dir> -a <gcda dir> -o <result dir>
   
   - Clang path, same board with `CONFIG_COVERAGE_SOURCE=y` and a clang build:
   
     $ ./tools/gcov.py -e nuttx -a <profraw dir> -o <result dir>
   
   - `genhtml` report opened in a browser and compared against the previous
   gcc-only output; cross-toolchain tracefile merge exercised with
   `lcov --add-tracefile`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to