[llvm-dev] (Thin)LTO llvm build
Xinliang David Li via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 4 08:22:34 PDT 2016
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/fad39bef/attachment.html>
More information about the llvm-dev
mailing list