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>
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/a1cf0adc/attachment-0001.html>
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>