llvm dev - May 2014 - [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/20140524/42400489/attachment.html>

This was fixed by r216215

On 24 May 2014 10:04, Balaram Makam <bmakam at codeaurora.org>
wrote:
> 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
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>