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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
