[llvm-dev] (Thin)LTO llvm build
Teresa Johnson via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 4 06:58:24 PDT 2016
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/d3c452c5/attachment-0001.html>
More information about the llvm-dev
mailing list