code-coverage - GCOV 交叉分析 : __gcov_flush() does not flush coverage data for shared libraries

Question

我正在尝试获取基于 arm 的嵌入式系统的代码覆盖率。使用 x86 进行交叉编译。基本上，我有一个交叉分析问题。

对于我想要生成代码覆盖率数据的应用程序，我定义了一个信号处理程序，我在其中调用 __gcov_flush() 将代码覆盖率数据刷新到 .gcda 文件。我正在向应用程序发送 SIGUSR1。该应用程序使用多个 .so 文件，其中实现了大量代码和逻辑。

当我向进程发送信号时，仅为应用程序创建/更新了 .gcda 文件。 .so 的 .gcda 文件根本没有创建/更新。

有没有办法让 __gcov_flush() 刷新应用程序正在使用的 .so 的所有覆盖率数据？

我不想强制应用程序 exit() 因为那样会破坏我想要做的事情的目的。我需要能够转储应用程序的覆盖数据以及它在运行时使用的 .so。请帮忙!!

使用 ARM GCC v4.5.1。

这是我到目前为止为生成代码覆盖率数据所做的工作:

我在主联编文件中为 GCC 定义了以下选项:CFLAGS += -fprofile-arcs -ftest-coverageLDFLAGS += -fprofile-arcs -ftest-coverage

我还将 GCOV_PREFIX 和 GCOV_PREFIX_STRIP 导出为目标系统上的全局环境变量，以强制在特定路径中创建 .gcda 文件。这是有效的。

我唯一的问题是当从应用程序调用 __gcov_flush() 时，.so 的 .gcda 文件没有被创建/更新。

Answer 1

这个问题在 GCC 邮件列表上得到了回答。TLDR:需要在每个使用的共享库中添加一个处理程序，它将转储覆盖率数据。然后需要调用这些处理程序。

来自the mailing list的详细回答如下。

来自邮件列表的问题

On Fri, 19 Jun 2015, Utpal Patel wrote:

I am trying to get code coverage for an arm based embedded system. Using x86 for cross compilation.So basically, I have a cross profiling question.

For the application I want to generate code coverage data, I have defined a signal handler inside which I call __gcov_flush() to flush code coverage data to .gcda files. I am sending SIGUSR1 to the application. The application uses multiple .so files where bulk of the code and logic is implemented.

When I send the signal to the process, the .gcda files for just the application get created/updated. The .gcda files for the .so's are not created/updated at all.

Is there a way to make __gcov_flush() flush all the coverage data for the .so's that the application is using?

I dont want to force the application to exit() because that would defeat the purpose of what I am trying to do. I need to be able to dump coverage data for the application and the .so it uses at runtime. Please help!!

来自邮件列表的回答

When you compiled your application with -fprofile-arcs
-ftest-coverage only the application was instrumented (conceptually a 64bit counters in each basic block of the apps minimum spaning tree) and those counters are what __gcov_flush() is dumping.

So if you want profiling infos from libraries you need to compile the library for profiling as gcov is a static instrumentation and there is no way to get infos from a .so without that it was compiled for profiling just like your application. If the application is compiled for profiling then its data will be dumped when you call __gcov_flush() but since you can not send signals to a library to call some handler you would need to install some other mechanism in the library e.g. brute force put a

int libdump(void) {
        __gcov_flush();                                                         
}

into the library and call that from your application signal handler just like you called __gcov_flush(); now.

This is from a trivial library that just provides an open call that is a wrapper to libc open and the libdump function

    2:   77:int libdump(void) {
    2:   78:        __gcov_flush();
    1:   79:        return 0;
    -:   80:}
    -:   81:/* we now can get code coverage of the library */
  145:   82:int open(const char *pathname, int flags, mode_t mode) {
  145:   83:        return __open(pathname, flags, mode);
    -:   84:}

the library is compiled with

gcc -fPIC -Wall -g -O2 -fprofile-arcs -ftest-coverage -shared -o libgctest.so.0 libgc.c 

the application has the libdump() in the signal handler

int libdump(void);

void gc_handler(int signum)
{
        printf("received signal\n");
        __gcov_flush(); /* dump coverage data on receiving SIGUSR1 */
        libdump();      /* and dump library converage data */
}

and is compiled with

gcc -O2 -fprofile-arcs -ftest-coverage hello.c -o hello -lgctest
 `kill -10 <PIDOF application>` will now dump the gcda of both application and library.

HTH hofrat

ps: I have no clue why the count of the return 0 line in the libhandler does not have a count of 2 as well....