Bug 216871

Summary:	www/firefox: DTRACE=on no longer builds on 12.0-CURRENT
Product:	Ports & Packages	Reporter:	Jan Beich <jbeich>
Component:	Individual Port(s)	Assignee:	Mark Johnston <markj>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	dtrace, markj
Priority:	---	Keywords:	needs-patch
Version:	Latest	Flags:	bugzilla: maintainer-feedback? (gecko)
Hardware:	Any
OS:	Any

Description Jan Beich freebsd_committer

2017-02-07 02:34:55 UTC

../../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[6]: *** [/wrkdirs/usr/ports/www/firefox/work/firefox-51.0.1/config/rules.mk:802: libxul.so] Error 1

Comment 1 Mark Johnston freebsd_committer

2017-02-07 02:43:26 UTC

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.

Comment 2 Mark Johnston freebsd_committer

2017-02-07 18:10:47 UTC

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
function:

> 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.

Comment 3 Mark Johnston freebsd_committer

2017-02-09 20:16:10 UTC

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.

Comment 4 commit-hook freebsd_committer

2017-02-10 02:02:09 UTC

A commit references this bug:

Author: markj
Date: Fri Feb 10 02:01:32 UTC 2017
New revision: 313504
URL: https://svnweb.freebsd.org/changeset/base/313504

Log:
  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.

  PR:		216871
  X-MFC With:	r313262

Changes:
  head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.c