LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 31495 - LLD fails to link object file with version-extended symbol
Summary: LLD fails to link object file with version-extended symbol
Status: RESOLVED FIXED
Alias: None
Product: lld
Classification: Unclassified
Component: ELF (show other bugs)
Version: unspecified
Hardware: PC FreeBSD
: P normal
Assignee: Rafael Ávila de Espíndola
URL:
Keywords:
Depends on:
Blocks: 23214
  Show dependency tree
 
Reported: 2016-12-29 12:00 PST by emaste
Modified: 2017-01-06 16:45 PST (History)
4 users (show)

See Also:
Fixed By Commit(s):


Attachments
reduced testcase (579 bytes, application/x-bzip)
2017-01-05 17:46 PST, Rafael Ávila de Espíndola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description emaste 2016-12-29 12:00:42 PST
FreeBSD's "pkg" package management tool is currently building an object file that depends on a compatibility symbol. I think this needs to be addressed in pkg itself, but GNU ld is able to link such an object.

LLD reports:

% ld.lld $(cat response.txt)                                
/tank/emaste/src/llvm/build-nodebug/bin/ld.lld: error: wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.7.2/libpkg/.libs/libpkg.lax/libbsd_compat.a/libbsd_compat_la-basename.o: symbol basename@FBSD_1.0 has undefined version FBSD_1.0
/tank/emaste/src/llvm/build-nodebug/bin/ld.lld: error: wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.7.2/libpkg/.libs/libpkg.lax/libbsd_compat.a/libbsd_compat_la-dirname.o: symbol dirname@FBSD_1.0 has undefined version FBSD_1.0

ld.bfd has no complaints:
% ld.bfd $(cat response.txt)
% 

The offending symbol is basename@FBSD_1.0:

% readelf -s libbsd_compat_la-basename.o

Symbol table '.symtab' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS basename.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 
     3: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND basename@FBSD_1.0
     4: 0000000000000000    10 FUNC    GLOBAL DEFAULT    2 bsd_basename

And indeed, a .o file has no symver information:

% readelf -V libbsd_compat_la-basename.o

No version information found in this file.

I suspect we should accept version-extended symbols from object files. Reprodcer available at https://people.freebsd.org/~emaste/lld/object-sym-version.cpio
Comment 1 emaste 2016-12-29 12:15:35 PST
See also https://github.com/freebsd/pkg/issues/1522 for the pkg report.
Comment 2 emaste 2017-01-03 09:42:06 PST
pkg issue now addressed by https://github.com/freebsd/pkg/commit/05ce724323422f728b6a8c024e9822aec8bb2732
Comment 3 Rui Ueyama 2017-01-03 16:55:59 PST
This must be a LLD's bug. If there is an undefined symbol `foo@bar` in an object file and there is an DSO defining `foo` with version `bar`, the undefined symbol should be resolved using the shared symbol.
Comment 4 emaste 2017-01-03 20:37:08 PST
> This must be a LLD's bug.

I agree, if a foo@bar symbol appears in an object file lld should resolve it if the appropriate symbol and version appears in a DSO.

I just suspect that the use of such a symbol is reasonably likely to be unintentional, as it was with pkg. (Of course there also legitimate use cases for specific symbol versions, e.g. a unit test suite.)
Comment 5 Rafael Ávila de Espíndola 2017-01-05 17:46:20 PST
Created attachment 17810 [details]
reduced testcase

I reduced the testcase somewhat. I will try to fix this tomorrow if no one gets there first.
Comment 6 Rafael Ávila de Espíndola 2017-01-06 16:45:18 PST
291293