../../js/src/js-dtrace.o:(.SUNW_dof+0x360): undefined reference to `$dtrace7737474._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE'
/usr/bin/ld: final link failed: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [/wrkdirs/usr/ports/www/firefox/work/firefox-51.0.1/config/rules.mk:802: libxul.so] Error 1
This is a bit strange. I had hit this error while testing in preparation for r313262, but had fixed it before committing. I'll try to reproduce this.
The problem seems to be related to GNU ld (I had only tested the build
with lld) and -ffunction-sections. Two objects that get linked into libxul.so
contain the same weak symbol. There's a DTrace probe in the corresponding
> readelf -s Unified_cpp_js_src27.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC
747: 0000000000000000 518 FUNC WEAK HIDDEN 152 _ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
1261: 0000000000000000 518 FUNC GLOBAL HIDDEN 152 $dtrace6188451._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
> readelf -s jsarray.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC
382: 0000000000000000 518 FUNC WEAK HIDDEN 405 _ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
567: 0000000000000000 518 FUNC GLOBAL HIDDEN 405 $dtrace6195329._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
> readelf -s js-dtrace.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC
44: 0000000000000000 0 FUNC GLOBAL DEFAULT UND $dtrace6188451._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
57: 0000000000000000 0 FUNC GLOBAL DEFAULT UND $dtrace6195329._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
With r313262, we emit alises for the symbols. It seems that ld merges the
sections, and ends up leaving one the aliases orphaned:
> ld -r -o test.o jsarray.o Unified_cpp_js_src27.o
> readelf -s test.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC
1231: 0000000000000000 0 FUNC GLOBAL HIDDEN UND $dtrace6188451._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
1438: 0000000000000000 518 FUNC GLOBAL HIDDEN 476 $dtrace6195329._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
1667: 0000000000000000 518 FUNC WEAK HIDDEN 476 _ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE
However, the .SUNW_dof section has a relocation for this symbol, so the
final link fails.
I'm not sure if this behaviour is a bug in ld. It seems to me that we
might be able address this by avoiding the "$dtrace" uniquifier for aliases
of weak symbols.
I have a fix which addresses this. However, it's working around some linker behaviour that I don't understand; I've asked one of the LLD developers for some clarification. If I don't hear back today I'll commit the workaround as a temporary measure.
A commit references this bug:
Date: Fri Feb 10 02:01:32 UTC 2017
New revision: 313504
When patching USDT probes, use non-unique names for aliases of weak symbols.
Aliases are normally given names that include a key that's unique for each
input object file. This, for example, ensures that aliases for identically
named local symbols in different object files don't conflict. However, in
some cases the static linker will leave an undefined alias after merging
identical weak symbols, resulting in a link error. A non-unique name allows
the aliases to be merged as well.
X-MFC With: r313262