Bug 83879 - __gcov_dump doesn't work with dlopen-ed libraries
Summary: __gcov_dump doesn't work with dlopen-ed libraries
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: gcov-profile (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Martin Liška
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-15 23:28 UTC by Marco Castelluccio
Modified: 2018-03-07 09:51 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 8.0
Known to fail: 6.4.0, 7.3.0
Last reconfirmed: 2018-01-22 00:00:00


Attachments
Archive containing source files to reproduce the bug (735 bytes, application/x-xz)
2018-01-15 23:28 UTC, Marco Castelluccio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Castelluccio 2018-01-15 23:28:49 UTC
Created attachment 43144 [details]
Archive containing source files to reproduce the bug

See the attached example.

To reproduce the problem, run the "run.sh" script and see that no func.gcda or func2.gcda are generated.

If you remove the "pause()" call in main.c and let the program exit, the func.gcda and func2.gcda files are generated.
Comment 1 Martin Liška 2018-01-22 10:18:07 UTC
Confirmed, problem is that we create 2 shared libraries that both have __gcov_master symbol defined. When dlopen is used for the library:

#0  __gcov_init (info=0x7ffff7817160) at ../../../libgcc/libgcov-driver.c:904
#1  0x00007ffff7614070 in _GLOBAL__sub_I_00100_0_func.c () from ./func.shared
#2  0x00007ffff7de6b8a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdbe8, env=env@entry=0x7fffffffdbf8) at dl-init.c:72
#3  0x00007ffff7de6c96 in call_init (env=0x7fffffffdbf8, argv=0x7fffffffdbe8, argc=1, l=<optimized out>) at dl-init.c:119
#4  _dl_init (main_map=main_map@entry=0x607280, argc=1, argv=0x7fffffffdbe8, env=0x7fffffffdbf8) at dl-init.c:120
#5  0x00007ffff7deb3ee in dl_open_worker (a=a@entry=0x7fffffffd880) at dl-open.c:564
#6  0x00007ffff794d7c4 in __GI__dl_catch_error (objname=0x7fffffffd870, errstring=0x7fffffffd878, mallocedp=0x7fffffffd86f, operate=0x7ffff7deb060 <dl_open_worker>, args=0x7fffffffd880) at dl-error-skeleton.c:198
#7  0x00007ffff7deab99 in _dl_open (file=0x4034b8 "func.shared", mode=-2147483391, caller_dlopen=0x400e6f <main+73>, nsid=-2, argc=<optimized out>, argv=<optimized out>, env=0x7fffffffdbf8) at dl-open.c:649

Then we end up with situation where __gcov_master from main.c is different from the ones living in the shared libraries. And then we end with multiple __gcov_master symbols which is wrong. The symbol should live in the process image just once.

Nathan any ideas how to fix that?
Comment 2 Nathan Sidwell 2018-01-22 15:49:25 UTC
The multiple definitions of gcov_master should not be a problem.  The (ELF) semantics of shared libraries are such that the definition in the main program preempts the defiitions in the libraries.  The libraries' GOT entry for that symbol should point at the main program's instance.  That's the design intent, IIRC.

It looks like the shared objects are built with PIC libgcov:
0000000000000000 <__gcov_dump_int>:
   0:	48 8b 05 00 00 00 00 	mov    0x0(%rip),%rax        # 7 <__gcov_dump_int+0x7>
			3: R_X86_64_REX_GOTPCRELX	__gcov_master-0x4
   7:	53                   	push   %rbx
   8:	48 8d 1d 00 00 00 00 	lea    0x0(%rip),%rbx        # f <__gcov_dump_int+0xf>
			b: R_X86_64_PC32	__gcov_root-0x4
   f:	81 38 52 32 37 41    	cmpl   $0x41373252,(%rax)

So I presume that during loading the shared objects, they're not linking themselves into the gcov list.
Comment 3 Nathan Sidwell 2018-01-22 16:47:43 UTC
Aha, this is the behaviour of the static linker.  It is not placing '__gcov_master' into main's dynamic symbol table.  So dlloading the shared objects do not see it, and have their own instance.  To confuse things further, the first dlloaded object creates this symbol and the second loaded object sees that symbol.

from ld's man page:
         When creating a dynamically linked executable, using the -E option or the --export-dynamic option causes the linker
           to add all symbols to the dynamic symbol table.  The dynamic symbol table is the set of symbols which are visible
           from dynamic objects at run time.

           If you do not use either of these options (or use the --no-export-dynamic option to restore the default behavior),
           the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object
           mentioned in the link.

           If you use "dlopen" to load a dynamic object which needs to refer back to the symbols defined by the program, rather
           than some other dynamic object, then you will probably need to use this option when linking the program itself.

           You can also use the dynamic list to control what symbols should be added to the dynamic symbol table if the output
           format supports it.  See the description of --dynamic-list.

           Note that this option is specific to ELF targeted ports.  PE targets support a similar function to export all symbols
           from a DLL or EXE; see the description of --export-all-symbols below.


You can use '-dynamic' when invoking gcc to set this linker flag:
Pass the flag @option{-export-dynamic} to the ELF linker, on targets
that support it. This instructs the linker to add all symbols, not
only used ones, to the dynamic symbol table. This option is needed
for some uses of @code{dlopen} or to allow obtaining backtraces
from within a program.

Might be worth documenting this in gcov's options?
Comment 4 Marco Castelluccio 2018-01-22 18:57:27 UTC
Would it be feasible to force exporting "__gcov_master" to the dynamic symbol table when coverage instrumentation is enabled?
Comment 5 Nathan Sidwell 2018-01-22 19:07:11 UTC
usage is --dynamic-list=file-name, which would be a little awkward.  --dynamic-list-data is probably more useable and available.
Comment 6 Martin Liška 2018-02-05 09:19:59 UTC
Author: marxin
Date: Mon Feb  5 09:19:18 2018
New Revision: 257383

URL: https://gcc.gnu.org/viewcvs?rev=257383&root=gcc&view=rev
Log:
Document --dynamic-list-data option for --coverage usage.

2018-02-05  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/83879
	* doc/gcov.texi: Document necessity of --dynamic-list-data when
	using dlopen functionality.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/gcov.texi
Comment 7 Martin Liška 2018-02-05 09:20:40 UTC
Fixed on trunk, queued for backports.
Comment 8 Martin Liška 2018-03-06 20:07:17 UTC
Author: marxin
Date: Tue Mar  6 20:06:45 2018
New Revision: 258296

URL: https://gcc.gnu.org/viewcvs?rev=258296&root=gcc&view=rev
Log:
Backport r257383

2018-03-06  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2018-02-05  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/83879
	* doc/gcov.texi: Document necessity of --dynamic-list-data when
	using dlopen functionality.

Modified:
    branches/gcc-7-branch/gcc/ChangeLog
    branches/gcc-7-branch/gcc/doc/gcov.texi
Comment 9 Martin Liška 2018-03-07 09:48:43 UTC
Author: marxin
Date: Wed Mar  7 09:48:02 2018
New Revision: 258329

URL: https://gcc.gnu.org/viewcvs?rev=258329&root=gcc&view=rev
Log:
Backport r257383

2018-03-07  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2018-02-05  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/83879
	* doc/gcov.texi: Document necessity of --dynamic-list-data when
	using dlopen functionality.

Modified:
    branches/gcc-6-branch/gcc/ChangeLog
    branches/gcc-6-branch/gcc/doc/gcov.texi
Comment 10 Martin Liška 2018-03-07 09:51:15 UTC
Should be fixed on all active branches.