Bug 1612957 - Linker fails to resolve explitcitly referenced versioned symbol with '-flto'.
Summary: Linker fails to resolve explitcitly referenced versioned symbol with '-flto'.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: clang
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: serge_sans_paille
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-06 15:48 UTC by Björn Esser (besser82)
Modified: 2019-01-17 12:09 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-01-17 12:09:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Tarball with minimal testcase. (1.65 KB, application/x-gzip)
2018-08-06 15:48 UTC, Björn Esser (besser82)
no flags Details

Description Björn Esser (besser82) 2018-08-06 15:48:04 UTC
Created attachment 1473654 [details]
Tarball with minimal testcase.

Description of problem:

  Linker fails to resolve explitcitly referenced versioned symbol
  from an external DSO when building and linking an executable with
  LTO (-flto / -Wl,-flto) enabled.

  Doing the same with GCC everything works as expected.


Version-Release number of selected component (if applicable):

  clang-6.0.1-1.fc28

  clang version 6.0.1 (tags/RELEASE_601/final)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix


How reproducible:

  100%  (see attached testcase)


Steps to Reproduce:

  1. Run `make` from testcase (use GCC, works).
  2. Run `make clean`.
  3. Run `CC=clang make` (use Clang).
  4. *BANG*


Actual results:

  Linker fails to resolve the explicitly referenced symbol from DSO.


Expected results:

  Works, as when using GCC.


Additional info:

  source.c:LINENO: undefined reference to `foo@BAR_123'
  /usr/bin/ld: out.a: No symbol version section for versioned
                      symbol `foo@BAR_123'
  /usr/bin/ld: final link failed: Nonrepresentable section on output


  DSO symbols when built using Clang:

  $nm -gD --with-symbol-versions --special-syms libtestcase.so
  0000000000000000 A BAR_123@@BAR_123
  0000000000000000 A BAR_234@@BAR_234
                   w __cxa_finalize.5
  00000000000005e0 T foo@BAR_123
  00000000000005f0 T foo@@BAR_234
                   w __gmon_start__
                   w _ITM_deregisterTMCloneTable
                   w _ITM_registerTMCloneTable


  DSO symbols when built using GCC:

  $nm -gD --with-symbol-versions --special-syms libtestcase.so
  0000000000000000 A BAR_123@@BAR_123
  0000000000000000 A BAR_234@@BAR_234
                   w __cxa_finalize.5
  00000000000005f0 T foo@BAR_123
  00000000000005e0 T foo@@BAR_234
                   w __gmon_start__
                   w _ITM_deregisterTMCloneTable
                   w _ITM_registerTMCloneTable

  (The start addresses of the functions differ in GCC build with LTO.)


  I suspect the problem comes from the LLVMgold / libLTO plugin for ld.


  Fedora 28+ is affected, too.

Comment 1 Björn Esser (besser82) 2018-08-06 15:54:57 UTC
Version-Release number of selected component (if applicable):

  clang-6.0.1-1.fc28

  clang version 6.0.1 (tags/RELEASE_601/final)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix


  binutils-2.29.1-23.fc28

  GNU ld version 2.29.1-23.fc28


  llvm-libs-6.0.1-1.fc28

Comment 2 Jan Kurik 2018-08-14 10:26:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 3 Björn Esser (besser82) 2018-08-24 08:49:36 UTC
Still valid for Rawhide.

Comment 4 serge_sans_paille 2018-12-21 14:02:13 UTC
The bug has been fixed upstream - I cannot reproduce it with top-of-tree llvm version. I'll check if It's fixed in 7.0.1 that has just been released to rawhide and is in pending for f29.

Comment 5 serge_sans_paille 2018-12-21 16:04:16 UTC
Bug fixed on f29 with clang 7.0.0.

Comment 6 serge_sans_paille 2019-01-04 22:36:44 UTC
The bug was exactly fixed by this commit https://reviews.llvm.org/rL329651

@tstellar: should we backport that fix?

Comment 7 Tom Stellard 2019-01-07 17:35:19 UTC
Yes, let's backport this to llvm-6.0.1 in f28.

Comment 8 serge_sans_paille 2019-01-16 20:55:39 UTC
Unfortunately the patch would introduce API/ABI break, so we'd rather not apply the patch and don't fix this bug. considering f28 is at the end of its lifetime and that the bug is fixed in f29, this seems to be a reasonnable choice.

For reference, the patch was: https://src.fedoraproject.org/rpms/llvm/pull-request/7


Note You need to log in before you can comment on or make changes to this bug.