[llvm-dev] (Thin)LTO llvm build

Tue Oct 4 09:18:04 PDT 2016

Filed https://llvm.org/bugs/show_bug.cgi?id=30609 to track the issue.

David

On Tue, Oct 4, 2016 at 9:01 AM, Xinliang David Li <xinliangli at gmail.com>
wrote:

> Looks like there is a bug in LLVMgold plugin -- the visibility of the weak
> symbol is set to LDPV_DEFAULT instead of LDPV_HIDDEN.
>
> David
>
> On Tue, Oct 4, 2016 at 8:22 AM, Xinliang David Li <xinliangli at gmail.com>
> wrote:
>
>> GCC LTO works ok for the test case with both bfd and gold linker.
>>
>> David
>>
>> On Tue, Oct 4, 2016 at 6:58 AM, Teresa Johnson <tejohnson at google.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 3, 2016 at 6:15 PM, Teresa Johnson <tejohnson at google.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 3, 2016 at 5:24 PM, Xinliang David Li <xinliangli at gmail.com
>>>> > wrote:
>>>>
>>>>> Small repro:
>>>>>
>>>>> __attribute__((weak)) int hello_world();
>>>>>
>>>>> int test() {
>>>>>   if (hello_world)
>>>>>       return hello_world();
>>>>>   return 0;
>>>>> }
>>>>>
>>>>> $ clang -fuse-ld=gold  -flto=thin -O2 -shared -fPIC -o libmore.so
>>>>> more.c
>>>>> $ objdump -t libmore.so |grep hello
>>>>> 0000000000000000  w      *UND* 0000000000000000
>>>>>  hello_world
>>>>>
>>>>> $ clang -fuse-ld=bfd  -flto=thin -O2 -shared -fPIC -o libmore.so more.c
>>>>> $ objdump -t libmore.so |grep hello
>>>>> 0000000000000000       *UND* 0000000000000000              hello_world
>>>>>
>>>>
>>>> Same issue reproduces with just -flto (not just -flto=thin). So this is
>>>> a general issue with ld.bfd interactions with LLVMgold.so.
>>>>
>>>
>>> Oddly, if I do -Wl,-plugin-opt,save-temps, all of the temps files saved
>>> in both cases are exactly the same, including the native object file (which
>>> has a weak hello_world). So it is not that we are getting different input
>>> from ld.bfd, but rather that it is treating the returned object
>>> differently. And if I use the same command as above but replace the IR
>>> object with the saved native object, ld.bfd behaves correctly (the final
>>> .so has a weak symbol).
>>>
>>> I'm going to start a different thread about gold-plugin and ld.bfd
>>> interactions.
>>>
>>> Carsten, let me know if you are able to get ld.gold used for your build,
>>> as mentioned that is the better tested linker for LLVMgold.so.
>>>
>>> Thanks,
>>> Teresa
>>>
>>>
>>>>
>>>>>
>>>>> On Mon, Oct 3, 2016 at 4:40 PM, Teresa Johnson <tejohnson at google.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 3, 2016 at 3:53 PM, Xinliang David Li <
>>>>>> xinliangli at gmail.com> wrote:
>>>>>>
>>>>>>> What is the linker command line buidling liblldb.so? is libgcc.a
>>>>>>> passed in?
>>>>>>>
>>>>>>
>>>>>> There is no difference in the linker command for liblldb.so or
>>>>>> bin/lldb between the ld.bfd and ld.gold cases, and neither links libgcc.a
>>>>>> that I can see.
>>>>>>
>>>>>> The difference appears to be that the __morestack symbol is weak in
>>>>>> the ld.gold liblldb.so case (and simply doesn't appear in the resulting
>>>>>> bin/lldb presumably because libgcc.a is not linked):
>>>>>>
>>>>>> $ nm lib/liblldb.so.3.9.1 | grep morestack
>>>>>>                  w __morestack
>>>>>>
>>>>>> whereas it is an undef in the ld.bfd case:
>>>>>>
>>>>>> $ nm lib/liblldb.so | grep morestack
>>>>>>                  U __morestack
>>>>>>
>>>>>> resulting in the failure linking bin/lldb in that case.
>>>>>>
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On Mon, Oct 3, 2016 at 3:52 PM, Xinliang David Li <
>>>>>>> xinliangli at gmail.com> wrote:
>>>>>>>
>>>>>>>> In  uint64_t
>>>>>>>> RTDyldMemoryManager::getSymbolAddressInProcess(const std::string
>>>>>>>> &Name)  {
>>>>>>>>
>>>>>>>> there is reference to morestack:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> #if defined(__i386__) || defined(__x86_64__)
>>>>>>>>   // __morestack lives in libgcc, a static library.
>>>>>>>>   if (&__morestack && Name == "__morestack")
>>>>>>>>     return (uint64_t)&__morestack;
>>>>>>>> #endif
>>>>>>>> #endif // __linux__ && __GLIBC__
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Oct 3, 2016 at 3:32 PM, Teresa Johnson <
>>>>>>>> tejohnson at google.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Oct 3, 2016 at 2:59 PM, Xinliang David Li <
>>>>>>>>> xinliangli at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Is -fsplit-stack option used anywhere? My wild guess is that with
>>>>>>>>>> ld.bfd, the thinLTO link for the DSO does not bring in morestack.o from
>>>>>>>>>> libgcc.a, but the hidden symbol is defined in lldb binary.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> AFAICT, no - I had done "ninja -v" so I have all of the
>>>>>>>>> intermediate build commands, and it doesn't show up in that.
>>>>>>>>>
>>>>>>>>> I'll have to do some more digging to figure out why it is
>>>>>>>>> referenced from liblldb.so in the ld.bfd case and not when using ld.gold
>>>>>>>>>
>>>>>>>>> Teresa
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>> On Mon, Oct 3, 2016 at 1:54 PM, Teresa Johnson via llvm-dev <
>>>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Aha - finally reproduced! The difference is using ld.bfd not
>>>>>>>>>>> ld.gold. With that I get the same failure (using 3.9 to build 3.9 sources):
>>>>>>>>>>>
>>>>>>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld:
>>>>>>>>>>> bin/lldb-3.9.1: hidden symbol `__morestack' in
>>>>>>>>>>> /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(morestack.o) is
>>>>>>>>>>> referenced by DSO
>>>>>>>>>>> /usr/local/google/home/tejohnson/binutils_build/install/bin/ld:
>>>>>>>>>>> final link failed: Bad value
>>>>>>>>>>> clang-3.9: error: linker command failed with exit code 1 (use -v
>>>>>>>>>>> to see invocation)
>>>>>>>>>>> ninja: build stopped: subcommand failed.
>>>>>>>>>>>
>>>>>>>>>>> I am not sure what the official support story is for LLVMgold.so
>>>>>>>>>>> and ld.bfd. As mentioned earlier, the LLVM site indicates it should use the
>>>>>>>>>>> gold linker. Can you use that while I try to figure out whether this is
>>>>>>>>>>> something that should be supported/working?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Teresa
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Oct 3, 2016 at 9:56 AM, Carsten Mattner <
>>>>>>>>>>> carstenmattner at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Oct 3, 2016 at 3:50 PM, Teresa Johnson <
>>>>>>>>>>>> tejohnson at google.com> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner <
>>>>>>>>>>>> carstenmattner at gmail.com> wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson <
>>>>>>>>>>>> tejohnson at google.com> wrote:
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > > I use trunk, but it depends on how close to the bleeding
>>>>>>>>>>>> edge you
>>>>>>>>>>>> > > > are comfortable with. But like I said, I also tried
>>>>>>>>>>>> bootstrapping
>>>>>>>>>>>> > > > with 3.9 (both trunk as well as 3.9 sources) and couldn't
>>>>>>>>>>>> reproduce.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> Hmm, so you're saying neither fails for you, right?
>>>>>>>>>>>> >
>>>>>>>>>>>> > Yes
>>>>>>>>>>>>
>>>>>>>>>>>> Okay. Do you mind focusing on the 3.9 branch? It's less of a
>>>>>>>>>>>> moving target
>>>>>>>>>>>> and lends itself more to figuring out what's failing for me.
>>>>>>>>>>>>
>>>>>>>>>>>> As soon as I get around to it, I'll send you my full configure
>>>>>>>>>>>> and build
>>>>>>>>>>>> steps as a shell script. Need to streamline it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>>>>>>>>>> 408-460-2413
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> LLVM Developers mailing list
>>>>>>>>>>> llvm-dev at lists.llvm.org
>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>>>>>>>> 408-460-2413
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>>>>> 408-460-2413
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>>> 408-460-2413
>>>>
>>>
>>>
>>>
>>> --
>>> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>>> 408-460-2413
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/2b8eb4fc/attachment.html>