search for: llvm_writeout_files

...tion_list - llvm_gcda_emit_arcs - llvm_gcda_emit_function - llvm_gcda_end_file - llvm_gcda_increment_indirect_counter - llvm_gcda_start_file - llvm_gcda_summary_info - llvm_gcov_init - llvm_register_flush_function - llvm_register_writeout_function - llvm_writeout_files Defining these function as "hidden" prevents a shared library from exporting them in its interface. The end-result is that each profiled shared library will be guaranteed to get its own set of the GCDA functions extracted from libclang_rt.profile.a. These GCDA functions are referencing...

...rcs -ftest-coverage and the coverage's at-exit hook takes 22 seconds, which is 44x more than I am willing to pay. Most of the time is spent here: #0 0x00007ffff3b034cd in msync () at ../sysdeps/unix/syscall-template.S:82 #1 0x0000000003a8c818 in llvm_gcda_end_file () #2 0x0000000003a8c914 in llvm_writeout_files () #3 0x00007ffff2f5e901 in __run_exit_handlers The test depends on ~700 source files and so the profiling library calls msync ~700 times. Full chromium depends on ~12000 source files, so we'll be dumping the coverage data for 5 minutes this way. I understand that we have to support the lcov/g...

Hello, I have few questions about coverage. Is there any user-facing documentation for clang's "-coverage" flag? The coverage instrumentation seems to happen before asan, and so if asan is also enabled asan will instrument accesses to @__llvm_gcov_ctr. This is undesirable and so we'd like to skip these accesses. Looks like GEP around @__llvm_gcov_ctr have special metadata