Balaram Makam
2014-May-27 21:06 UTC
[LLVMdev] Link time inlining vs compile time inlining (was RE: gold linker failing to resolve weak undefined symbol)
Changing the subject line and reposting the question. Bumping up to make sure that this post was not lost during the holidays ;) Appreciate any feedback. Thanks, Balaram From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Balaram Makam Sent: Saturday, May 24, 2014 10:04 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] gold linker failing to resolve weak undefined symbol Hi, I am experimenting with an inline strategy wherein I postpone inlining to link time rather than inlining at compile time, but I am facing runtime failure and wonder if anyone else saw this. Here is my sample test case: $ cat test.cpp #include <sstream> int main() { std::stringstream ss; ss << "hello"; ss.str(); } To test my inline strategy, I compile at O1 and use flto with gold plugin as below: clang -O1 -flto -Wl,-fuse-ld=gold -static test.cpp -o test.exe But the executable segfaults due to a weak undefined symbol: Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x000221e6 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::str() const () #2 0x00009020 in main () $ nm test.exe|grep _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag w _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag Note that the symbol value is null for the symbol _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag in the symbol table. However, when I compile at O3 and use flto with gold plugin, the linker is able to resolve the symbol correctly and there is no runtime failure: clang -O3 -flto -Wl,-fuse-ld=gold -static test.cpp -o test.exe $ nm test.exe|grep _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag 00030139 W _ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag Has anyone seen this issue before? Could this be an issue with the gold linker? Is it a bad design strategy to postpone inlining to link stage? Thanks, Balaram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140527/b0dbbd3d/attachment.html>