[Bug gold/22448] New: Undefined symbol in both shared library and plugin-added object does not trigger archive rescan

[sjc+binutils_bugzilla at immunant dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22448

            Bug ID: 22448
           Summary: Undefined symbol in both shared library and
                    plugin-added object does not trigger archive rescan
           Product: binutils
           Version: 2.30 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: sjc+binutils_bugzilla at immunant dot com
                CC: ian at airs dot com
  Target Milestone: ---

Created attachment 10604
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10604&action=edit
archive containing dso1.c, dso2.c, and lto.c

Background: Clang adds calls to __mulodi4 for trapping long long multiplies
when building with -ftrapv on 32-bit platforms. This call is added during LTO
compilation, so the symbol is undefined only when the LTO plugin adds the newly
compiled object.

If a shared library contains an undefined symbol and the LTO plugin adds a
reference to that undefined symbol in a new object, the newly undefined symbol
does not properly trigger a rescan of the archives to attempt to resolve the
symbol.


There are probably easier ways to reproduce, but the basic requirement is that
LTO adds a call to a previously unseen symbol. To reproduce this bug the way I
did using a stock clang and LLVM LTO plugin, you will need an archive
containing the implementation of __mulodi4 (found in clang's compiler-rt
builtins). In the following instructions I call this archive
libcompiler_rt-extras.a since that's what is available in AOSP. Build the
attached source file archive as follows for 32-bit x86 (can also reproduce on
32-bit ARM):

Build libdso1.so, which will contain an implementation of __mulodi4:
  clang dso1.c -c -ftrapv -m32
  clang dso1.o libcompiler_rt-extras.a -o libdso1.so -shared -ftrapv
-Wl,-no-undefined -fuse-ld=gold -m32

  readelf -s libdso1.so | grep mulodi4
     6: 00000570   265 FUNC    GLOBAL DEFAULT   11 __mulodi4                    
    43: 00000570   265 FUNC    GLOBAL DEFAULT   11 __mulodi4

Build libdso2.so, which does _not_ contain an implementation of __mulodi4 and
links against the implementation in libdso1.so:
  clang dso2.c -c -ftrapv -m32
  clang dso2.o libdso1.so -o libdso2.so -shared -ftrapv -Wl,-no-undefined
-fuse-ld=gold -m32

  readelf -s libdso2.so | grep mulodi4
     2: 00000000     0 FUNC    GLOBAL DEFAULT  UND __mulodi4                    
    20: 00000000     0 FUNC    GLOBAL DEFAULT  UND __mulodi4

Build liblto.so, which will fail to link:
  clang lto.c -c -flto -ftrapv -m32
  clang lto.o libcompiler_rt-extras.a libdso2.so -o liblto.so -shared -ftrapv
-flto -Wl,-no-undefined -fuse-ld=gold -m32

    /tmp/lto-llvm-3b7070.o:ld-temp.o:function lto: error: undefined reference
to '__mulodi4'

-- 
You are receiving this mail because:
You are on the CC list for the bug.