Bug 13742 – undefined reference to __coverage

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-11-17T10:51:41Z
Last change time
2018-01-16T04:41:43Z
Keywords
pull
Assigned to
No Owner
Creator
Martin Nowak

Comments

Comment #0 by code — 2014-11-17T10:51:41Z
This happens when building a smaller vibe.d app with -unittest and -cov. It only happens when vibe.d was build as static library, not when it's directly compiled with the application. Still need to reduce a test case.
Comment #1 by code — 2015-01-03T00:09:29Z
Another occurence of this issue. https://github.com/kiith-sa/D-YAML/issues/20
Comment #2 by jiki — 2015-03-28T11:12:57Z
I hit this on Windows. Reduced test case is here. COMMAND: dmd -cov -g -c test.d f.d dmd -cov -g -main test.obj f.obj OUTPUT: Error 42: Symbol Undefined ___coverage --- errorlevel 1 SOURCE FILES: f.d --------------------- import std.algorithm; void func(alias pred)() { int[] range; range.find!pred(0); } --------------------- test.d --------------------- import f; enum mypred = (int a, int b)=>false; //bool mypred(int a, int b) { return false; } -- WORK AROUND void test() { func!mypred(); } ---------------------
Comment #3 by code — 2015-04-13T14:49:10Z
(In reply to jiki from comment #2) > I hit this on Windows. > Reduced test case is here. Also confirmed for linux. A temporary workaround for your case is to only generate a single object file. dmd -cov -g -c -oftmp.o test.d f.d dmd -cov -g -main tmp.o Hope that also works on Windows.
Comment #4 by sludwig — 2016-02-02T12:19:56Z
For completeness sake, this is what I reduced from vibe.d: foo.d --- import bar; void clear() { void foo() {} performLocked!(() => foo); } --- bar.d --- import core.thread; void performLocked(alias PROC)() { assert(false); } --- main.d --- import foo; void main() {} --- dmd -lib -oflib.a bar.d foo.d -cov dmd -oftest lib.a main.d -cov -> lib.a(foo.o):foo.d:function _D3bar50__T13performLockedS28_D3foo5clearFZ9__lambda2MFZvZ13performLockedMFNaNbNiNfZv: error: undefined reference to '__coverage'
Comment #5 by code — 2018-01-07T05:11:41Z
Apparently happens because the __coverage symbols is defined twice in foo.o (2.078.0), once as BSS symbols and once as undefined symbol. nm lib.a foo.o: 0000000000000000 t 0000000000000000 d __bcoverage 0000000000000000 b __coverage U __coverage U _D3bar12__ModuleInfoZ Interestingly works when you swap foo.d and bar.d on the command line.
Comment #6 by code — 2018-01-07T06:17:37Z
The problem seems to be that the `performLocked!(() => foo);` has a location in bar.d and tries to increment bar's location, but the bar object is already emitted. When objects are done all symbols get reset and further references from other objects add an external undefined symbol, this seems to trigger the linker bug. As __coverage is local (static) symbol, referencing it from another object file isn't possible atm. anyhow. So I think the root cause is that the compile order bar.d foo.d ends up moving the nested template function pure nothrow @nogc @safe void bar.performLocked!(foo.clear().foo()).performLocked(int) to the foo.o object, where it can no longer reference bar.d's coverage symbol.
Comment #7 by code — 2018-01-10T00:12:16Z
Comment #8 by github-bugzilla — 2018-01-16T04:41:42Z
Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/69e7bd18892df18f682906916bf8c8ad87fb30e5 fix Issue 13742 - undefined reference to __coverage - Nested template functions may reference coverage symbols of other modules. Those coverage symbols are either still `null` or already `symbol_reset`, in the former case coverage instrumentation is silently skipped, in the later case the linker will cause an error. This is because the current object file ends up with two `__coverage` symbols, one local BSS symbols and an undefined external symbol (for the other module's coverage). - Fixed by mangling the symbols as _D3pkg3mod__coverageZ (similar to __ModuleInfoZ) and making them global. - Ideally the symbols would use -visibility=hidden, but that ELF backend feature isn't yet accessible from glue.d. - This does not fix missing coverage when the referenced module hasn't yet been codegen'ed (e.g. because it follows on the command line or is part of another separate compilation). Using weak linkage to make this heuristically work would incurr some overhead for the coverage instrumentation. Unconditionally referencing coverage info OTOH might be too excessive, e.g. when the template function is in phobos, which would require to recompile phobos with -cov for successful linking. https://github.com/dlang/dmd/commit/0cb16110c307b608034d49289e2a650e7d7d7dd8 Merge pull request #7654 from MartinNowak/fix13742 fix Issue 13742 - undefined reference to __coverage