How to see testing-coverage using gcov?

[PhilippRados]

I'm sorry if this is the wrong place to ask this question but I couldn't find any other way. I want to see the code coverage my tests have on the source files they test. Since I have multiple test-files I have to link them together first to combine them into one executable. However when I add the gcc-coverage flags it only produces the .gcno files for the single files and not the compiled executable. Plus it doesn't enter the underlying functions to test rather just the coverage in the testing files which is unnecessary. This is my Makefile:

# -*- Makefile -*-

CC = gcc-11
CFLAGS = -g -fsanitize=address -fsanitize=leak
TEST_COVERAGE = -fprofile-arcs -ftest-coverage
OBJECTS = src/bin/main.o src/bin/util.o src/bin/tab_complete.o src/bin/fuzzy_finder.o
TEST_OBJECTS = tests/bin/test_main.o tests/bin/test_util.o tests/bin/test_fuzzy_finder.o tests/bin/test_tab_complete.o
TEST_SOURCES = tests/test_main.c tests/test_util.c tests/test_fuzzy_finder.c tests/test_tab_complete.c

src/bin/%.o: src/%.c
	$(CC) $(CFLAGS) -c $< -o $@

tests/bin/%.o: tests/%.c
	$(CC) $(CFLAGS) ${TEST_COVERAGE} -c $< -o $@

run_tests: $(TEST_OBJECTS) $(OBJECTS) ## Run all tests
	${CC} ${CFLAGS} -fprofile-arcs -lgcov --coverage -o ./tests/bin/compiled_tests ${TEST_OBJECTS} src/bin/util.o src/bin/tab_complete.o src/bin/fuzzy_finder.o  \
		-L/usr/local/Cellar/criterion/2.3.3/lib/ -lcriterion.3.1.0
	./tests/bin/compiled_tests -l
	./tests/bin/compiled_tests

I want the coverage to be for the /tests/bin/compiled_tests - file which includes all tests and then to be able to see how much these tests cover in the actual source-files.

[Snaipe]

Last time I checked I did not have issues with gcov. A couple of questions:

1. I'm seeing you're on macOS; is gcc-11 actually gcc, or is it clang in disguise?
2. Can you try tracing open()s when running the test binary to check whether the .gcna files are being generated in any way? (dtruss -f -t open ./tests/bin/compiled_tests)

[PhilippRados]

1. No It's actually gcc I have to specify a version to make sure.
2. For this I have to deactivate system integrity and it says I have to do that from recovery os and I'm not really sure what the consequences are since I have never done that + (I have no idea what recovery OS actually is)
   Maybe the first step would be to make it actually show the coverage of the actual source files. Since the single files do create all the .gcno and .gcda files, but they dont show the underlying source code coverage:

[Snaipe]

Oh, I thought from the initial post that the .gcna files were missing altogether.

Clearly, the test code above seem to show that coverage is working (with all .c files in tests being near-100% covered). I think this is happening because you did not add instrumentation to your actual .o files. In particular, the following:

src/bin/%.o: src/%.c
	$(CC) $(CFLAGS) -c $< -o $@

Should be:

src/bin/%.o: src/%.c
	$(CC) $(CFLAGS) $(TEST_COVERAGE) -c $< -o $@

[PhilippRados]

I think I found the problem but still dont know how to solve it. When I try to read the src files with gcov it says

which happens for all source files that use functions from util.c.

I googled it and it said that it had to do with the different .gcda files being out if sync due to changes but that can't be the case because it deleted all files and only tried running the single test and still nothing.

I think its the structure of files that causes gcov the hiccups. I have a util.c file which holds all utility functions needed everywhere in the project. Every other header-file imports util.h which has an include guard. Every other file has it own header files where all the functions to test reside.

[Snaipe]

To be clear, do the .gcda files under src/bin/ exist? Are any of them missing? And you made sure to compile src/bin/main.o, src/bin/util.o, src/bin/tab_complete.o, and src/bin/fuzzy_finder.o with -fprofile-arcs -ftest-coverage right?

If all of these are true, then I'm a bit stumped. At that point I would try tracing the open() and fcntl syscalls using whatever tracing facility is allowed to run on a macbook and verify that multiple processes aren't trying to stomp on each others without locking, especially after seeing that message about the .gcda file being invalid.

[PhilippRados]

This is the dtrace traceback:

There seems to be a memory error