https://sourceware.org/bugzilla/show_bug.cgi?id=19842
Bug ID: 19842
Summary: LTO build fails to write call address for weak symbol
reference
Product: binutils
Version: 2.26
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: matt at godbolt dot org
CC: ian at airs dot com
Target Milestone: ---
I have a large, proprietary project which links with an open source project.
The large project ("hippo") is compiled with GCC 5.2, -O3, -flto, -fuse-ld=gold
and -fuse-linker-plugin. The open source project ("seasocks":
https://github.com/mattgodbolt/seasocks ) is compiled into a library archive
with "-O0" and a normal, non-LTO build.
Both projects use the exact same compiler version and -std=c++1y. No ODR
violations are noted during link, and we build cleanly with -Wall -Werror
-Wextra -pedantic
Both projects use (amongst many things) std::function<void()>. If I link the
two projects together, a call to std::function<void()>::~function as defined in
the non-LTO project seemingly is left as a "callq 0" :
Dump of assembler code for function std::_List_node<std::function<void ()>
>::~_List_node():
0x0000000000763f50 <+0>: push %rbp
0x0000000000763f51 <+1>: mov %rsp,%rbp
0x0000000000763f54 <+4>: sub $0x10,%rsp
0x0000000000763f58 <+8>: mov %rdi,-0x8(%rbp)
0x0000000000763f5c <+12>: mov -0x8(%rbp),%rax
0x0000000000763f60 <+16>: add $0x10,%rax
0x0000000000763f64 <+20>: mov %rax,%rdi
0x0000000000763f67 <+23>: callq 0x0
0x0000000000763f6c <+28>: nop
0x0000000000763f6d <+29>: leaveq
0x0000000000763f6e <+30>: retq
End of assembler dump.
Obviously this causes a run-time crash when executed (here it is manifested
only in a std::list<std::function<void()>>).
If I link using the normal ld (identical flags, but dropping the
-fuse-ld=gold), then all works ok:
Dump of assembler code for function std::_List_node<std::function<void ()>
>::~_List_node():
0x000000000077e880 <+0>: push %rbp
0x000000000077e881 <+1>: mov %rsp,%rbp
0x000000000077e884 <+4>: sub $0x10,%rsp
0x000000000077e888 <+8>: mov %rdi,-0x8(%rbp)
0x000000000077e88c <+12>: mov -0x8(%rbp),%rax
0x000000000077e890 <+16>: add $0x10,%rax
0x000000000077e894 <+20>: mov %rax,%rdi
0x000000000077e897 <+23>: callq 0x4ff020 <std::function<void
()>::~function()@plt>
0x000000000077e89c <+28>: nop
0x000000000077e89d <+29>: leaveq
0x000000000077e89e <+30>: retq
End of assembler dump.
I first reported this issue on the gcc-help mailing list:
https://gcc.gnu.org/ml/gcc-help/2016-03/msg00066.html and there I was directed
here. There is further information on that thread, in particular where I tried
using symbol tracing and debug options to gold.
Try as I might I've been unable to come up with a simple repro case. I
appreciate this makes this kind of bug very difficult.
I'm filing this in the hope someone can help me direct both my testing and
reproduction steps. I also appreciate there may still yet be some uncaught ODR
violation.
Many thanks in advance, Matt
--
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
