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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/1e4a8f6b/attachment.html>
What is the linker command line buidling liblldb.so? is libgcc.a passed in? 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 >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/0868ea22/attachment.html>
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>
I've given up on this for the moment and will try again when 5.0 comes around, hoping CI already has such a successful profile in the build matrix already. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170409/76c2d2a3/attachment.html>