xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Re: failed to get gcov result for libelf_* files
@ 2016-05-02  9:51 Zhangbo (Oscar)
  0 siblings, 0 replies; 2+ messages in thread
From: Zhangbo (Oscar) @ 2016-05-02  9:51 UTC (permalink / raw)
  To: Zhangbo (Oscar), xen-devel; +Cc: Chengaorang, Wangyufei (James), zhuweilun


>Hi all:
>    I'm backporting gcov-related patches(68ca0bc4ba -> 922153cd37) to xen
>4.1.2, but encountered with several problems, one problem is as follows:
>    1) although all the files are gathered into gcov_info_list correctly by
>__gcov_init(), but when we call write_gcov(), 3 gcov_info seem had been broken.
>       xen/common/libelf/libelf-tools.c
>       xen/common/libelf/libelf-loader.c
>       xen/common/libelf/libelf-dominfo.c
>
>    info->filename of theis are NULL, thus when we call write_gcov() ->
>write_string() -> strlen(), segment fault and kernel panic occurs.
>
>    2)  even if we fixed the above problem by:
>        If ( !info->filename )
>            continue;
>       inside write_gcov(),  I found that the info next to the problem one is
>null, thus, files after the problem one all get skipped. ( we only get 200 gcda files
>although we have 262 source files in total)
>
>    3) I 'fixed' this by modify __gcov_init():
>       void __gcov_init(struct gcov_info *info)
>       {
>           /* add new profiling data structure to list */
>      +    n_info_list ++;
>      +    if (n_info_list >= 61 && n_info_list <=63) {
>      +       printk("skip:%d\n", n_info_list);
>      +       return;
>      +    }
>           info->next = info_list;
>           info_list = info;
>       }
>       Then the files after these 3 files are not affected. We got 259 gcda files
>then.
>

I found that OBJCOPY is related to the problem! If I remove the OBJCOPY process in the Makefile of libelf, the problem got 'fixed':

diff --git a/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile b/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile
index 854e738..f522ae0 100755
--- a/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile
+++ b/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile
@@ -1,9 +1,9 @@
 obj-y := libelf.o

-SECTIONS := text data rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) $(foreach r,rel rel.ro,data.$(r) data.$(r).local)
+#SECTIONS := text data rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) $(foreach r,rel rel.ro,data.$(r) data.$(r).local)

-libelf.o: libelf-temp.o Makefile
-       $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
+#libelf.o: libelf-temp.o Makefile
+#      $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@

-libelf-temp.o: libelf-tools.o libelf-loader.o libelf-dominfo.o #libelf-relocate.o
+libelf.o: libelf-tools.o libelf-loader.o libelf-dominfo.o #libelf-relocate.o
        $(LD) $(LDFLAGS) -r -o $@ $^

It's still not the final solution. What's objcopy here used for? What bad result will happen if I remove it here? Thanks.


>    But, my solution obviously is the not the right solution, what's special about
>the 3 files? Why are their gcov_info get modified(filename changed to NULL)
>between __gcov_init() and write_gcov()? What's your suggestion to debug the
>problem?
>
>    Thanks in advance.
>
>   Oscar.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* failed to get gcov result for libelf_* files
@ 2016-05-02  8:06 Zhangbo (Oscar)
  0 siblings, 0 replies; 2+ messages in thread
From: Zhangbo (Oscar) @ 2016-05-02  8:06 UTC (permalink / raw)
  To: xen-devel; +Cc: Chengaorang, Wangyufei (James), zhuweilun

Hi all:
    I'm backporting gcov-related patches(68ca0bc4ba -> 922153cd37) to xen 4.1.2, but encountered with several problems, one problem is as follows:
    1) although all the files are gathered into gcov_info_list correctly by __gcov_init(), but when we call write_gcov(), 3 gcov_info seem had been broken.
       xen/common/libelf/libelf-tools.c
       xen/common/libelf/libelf-loader.c
       xen/common/libelf/libelf-dominfo.c

    info->filename of theis are NULL, thus when we call write_gcov() -> write_string() -> strlen(), segment fault and kernel panic occurs.

    2)  even if we fixed the above problem by:
        If ( !info->filename )
            continue;
       inside write_gcov(),  I found that the info next to the problem one is null, thus, files after the problem one all get skipped. ( we only get 200 gcda files although we have 262 source files in total)

    3) I 'fixed' this by modify __gcov_init():
       void __gcov_init(struct gcov_info *info)
       {
           /* add new profiling data structure to list */
      +    n_info_list ++;
      +    if (n_info_list >= 61 && n_info_list <=63) {
      +       printk("skip:%d\n", n_info_list);
      +       return;
      +    }
           info->next = info_list;
           info_list = info;
       }
       Then the files after these 3 files are not affected. We got 259 gcda files then.

    But, my solution obviously is the not the right solution, what's special about the 3 files? Why are their gcov_info get modified(filename changed to NULL) between __gcov_init() and write_gcov()? What's your suggestion to debug the problem?

    Thanks in advance.

   Oscar.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-05-02  9:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-02  9:51 failed to get gcov result for libelf_* files Zhangbo (Oscar)
  -- strict thread matches above, loose matches on Subject: below --
2016-05-02  8:06 Zhangbo (Oscar)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).