This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ppc64le: expected localentry:0 `pthread_condattr_destroy'


On Thu, Jul 27, 2017 at 06:34:33PM +0200, Florian Weimer wrote:
> On 07/27/2017 11:55 AM, Florian Weimer wrote:
> > On 07/27/2017 06:04 AM, Alan Modra wrote:
> >>>>> On 07/25/2017 09:11 PM, Josh Stone wrote:
> >>>>>> ./bin/rustc: error while loading shared libraries:
> >>>>>> ./lib/libstd-c3a1748e15265da7.so: expected localentry:0
> >>>>>> `pthread_condattr_destroy'
> >>
> >> You will get this error if the link-time version of a function symbol
> >> is seen as localentry:0 (ie. not needing a global entry point due to
> >> not needing a valid r2 toc pointer), but the run-time version does.
> >>
> >> The most likely thing is that your library was linked against a stub
> >> version of pthread_condattr_destroy.  Making the stub weak will
> >> disable the generation of the optimized localentry:0 plt call code.
> >> So will linking with -Wl,--no-plt-localentry
> > 
> > The common theme seems to be that this only affects symbols which live
> > both in libpthread and libc.  Do you suggest that we have to make the
> > implementation in libc a weak symbol?

Right, the stub symbols in libpthread.so should be make weak.
See my comment in pr21847.  We're getting a mismatch between ld symbol
resolution and ld.so resolution.

> > Why isn't this a plain regression break ELF symbol interposition?
> > 
> > I filed a glibc bug for this:
> > 
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=21847
> > 
> > I think we need to sort this out before the release.  That does not mean
> > we have to fix it, we just need a better understanding what is going on.
> 
> I injected -Wl,--no-plt-localentry into the build, using this patch:
> 
> --- a/sysdeps/powerpc/powerpc64le/Makefile
> +++ b/sysdeps/powerpc/powerpc64le/Makefile
> @@ -6,6 +6,10 @@
>  # linked executables, forcing to link the loader after libgcc link.
>  f128-loader-link = $(as-needed) $(elf-objpfx)ld.so $(no-as-needed)
> 
> +sysdep-LDFLAGS += -Wl,--no-plt-localentry
> +# Linking libc_pic.os ignores sysdep-LDFLAGS.
> +LDFLAGS-c_pic.os += -Wl,--no-plt-localentry
> +
>  ifeq ($(subdir),math)
>  # sqrtf128 requires emulation before POWER9.
>  CPPFLAGS += -I../soft-fp
> 
> But the issue persists afterwards.  I'm afraid we'll need a real fix.

No, you misunderstood my comment about --no-plt-localentry.  The
*user* library would need to be built with that option, which isn't a
good solution.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]