mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
master
rust/tests/coverage/long_and_wide.cov-map

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

37 lines
1.1 KiB
Plaintext
Raw Permalink Normal View History

Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-13 22:00:28 -05:00
Function name: long_and_wide::far_function
Raw bytes (10): 0x[01, 01, 00, 01, 01, 96, 01, 01, 00, 15]
Number of files: 1
- file 0 => global file 1
Number of expressions: 0
Number of file 0 mappings: 1
- Code(Counter(0)) at (prev + 150, 1) to (start + 0, 21)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-07 21:13:05 -05:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-13 22:00:28 -05:00
Function name: long_and_wide::long_function
Raw bytes (10): 0x[01, 01, 00, 01, 01, 10, 01, 84, 01, 02]
Number of files: 1
- file 0 => global file 1
Number of expressions: 0
Number of file 0 mappings: 1
- Code(Counter(0)) at (prev + 16, 1) to (start + 132, 2)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-07 21:13:05 -05:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-13 22:00:28 -05:00
Function name: long_and_wide::main
Raw bytes (9): 0x[01, 01, 00, 01, 01, 07, 01, 04, 02]
Number of files: 1
- file 0 => global file 1
Number of expressions: 0
Number of file 0 mappings: 1
- Code(Counter(0)) at (prev + 7, 1) to (start + 4, 2)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-07 21:13:05 -05:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-13 22:00:28 -05:00
Function name: long_and_wide::wide_function
Raw bytes (10): 0x[01, 01, 00, 01, 01, 0e, 01, 00, 8b, 01]
Number of files: 1
- file 0 => global file 1
Number of expressions: 0
Number of file 0 mappings: 1
- Code(Counter(0)) at (prev + 14, 1) to (start + 0, 139)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-07 21:13:05 -05:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-13 22:00:28 -05:00
Reference in New Issue Copy Permalink