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