[llvm-dev] (Thin)LTO llvm build

Teresa Johnson via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 3 18:15:45 PDT 2016


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.


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/97226507/attachment.html>


More information about the llvm-dev mailing list