When running coverage with clang as compiler i am getting the following

[Marcus Hines]

ERROR: /usr/local/google/home/hines/yeti/common/libs/transport/BUILD:496:1: Linking of rule '//common/libs/transport:websocket_test' failed (Exit 1)

external/crosstool/toolchain/bin/ld: error: cannot find -lgcov

I am assuming it is coming from:

def _coverage_feature(darwin):
  if darwin:
    compile_flags = """flag_group {
        flag: '-fprofile-instr-generate'
        flag: '-fcoverage-mapping'
      }"""
    link_flags = """flag_group {
        flag: '-fprofile-instr-generate'
      }"""
  else:
    compile_flags = """flag_group {
        flag: '-fprofile-arcs'
        flag: '-ftest-coverage'
      }"""
    link_flags = """flag_group {
        flag: '-lgcov'
      }"""

Since llvm requires a different set of paths does anyone know the right way to modify this?

[Marcus Hines]

Just to add some more color

I manually edited 

src/main/java/com/google/devtools/build/lib/rules/cpp/CppActionConfigs.java

 910                     "    flag_group {",

 911                     "      expand_if_all_available: 'gcov_gcno_file'",

 912                     "      flag: '-fprofile-arcs'",

 913                     "      flag: '-ftest-coverage'",

 914                     "    }",

 915                     "  }",

 916                     "  flag_set {",

 917                     "    action: 'c++-link-interface-dynamic-library'",

 918                     "    action: 'c++-link-dynamic-library'",

 919                     "    action: 'c++-link-executable'",

 920                     "    flag_group {",

 921                     "      flag: '-coverage'",

 922                     "    }",

 923                     "  }",

and now i am generating the *.gcno files

But no getting the .gcda files

But the code is now properly linking (which it did not before)

and running the tests which are passing

[Marcel Hlopko]

Hi Marcus,

so I think the code in unix_cc_configure doesn't work with clang, and should be removed completely. Then the code from CppActionConfigs would patch the crosstool at the loading phase and it should work (as it should work with clang correctly). Is that what you observe? 

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/ef1abf2d-cc68-4db3-8f0a-3306c553594b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

[Marcel Hlopko]

Oh, you maybe need to specify --experimental_use_llvm_covmap

[Marcus Hines]

Yep as you noted in your first reply unix_cc_configure doesn't do anything. I had added the change into the java  src/main/java/com/google/devtools/build/lib/rules/cpp/CppActionConfigs.java

to replace -lgcov to be --coverage

and was able to get it to almost work...

when running bazel coverage ... 

I could see the .gcno files getting generated however there were no gcda files produced even when the test said it was successful.

But if did then manually invoke the test subcommand  (found via bazel coverage -s ...)

This did produce the expected .gcda files however when doing a lcov i was getting an unexpected end of file (I think this is due to https://github.com/linux-test-project/lcov/commit/daca8d9febe52ccf1976240a3b48ffc350dec902)

I am currently upgrading to 1.13 to see if this fixes the problem)

But the fact i need to manually invoke the test to produce the .gcda files seems odd

Also following our advice in the 2nd message (-experimental_use_llvm_covmap) this actually seems to produce very similar results - i see .gcno files get generated (which I wouldn't have expected)

but no *.profraw

But when i manually invoke the test - i see the expected *.profraw and then i can use llvm-cov to produce a report