This is the mail archive of the
mailing list for the glibc project.
Re: ppc64: Call to gettimeofday fails with segfault in __glink_PLTresolve because .plt0 is all zeros.
- From: Alan Modra <amodra at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Date: Wed, 6 Nov 2013 09:41:42 +1030
- Subject: Re: ppc64: Call to gettimeofday fails with segfault in __glink_PLTresolve because .plt0 is all zeros.
- Authentication-results: sourceware.org; auth=none
- References: <52788890 dot 7080608 at redhat dot com> <20131105150331 dot GH20756 at bubble dot grove dot modra dot org> <5279664E dot 6040304 at redhat dot com>
On Tue, Nov 05, 2013 at 04:42:38PM -0500, Carlos O'Donell wrote:
> It is the critical combination of the new thread-safe plt stubs
> *and* the VDSO OPD being incomplete, followed by a dlopen with
> RTLD_NOW which cause the failure.
> The caller dlopen's the library with RTLD_NOW, thus the dynamic
> loader expects never to need .plt0 and doesn't set it up.
> However, because the IFUNC OPD has 0 for a TOC, because it's
> incomplete for some reason (the bug?), and because the new
> thread-safe plt sequences check for r2==0 and attempt a lazy
> resolution if it is, we end up in a situation where we are
> calling .glink0 without having setup .plt0.
Ah ha! That all makes sense, much better than my attempt to explain
the symptoms as due to calling an ifunc in an unrelocated library..
> This combination of events happens with glibc's gettimeofday
> (new enough glibc with IFUNC for that symbol) when called from
> librpmio.so.1 from python (which always uses RTLD_NOW with
> dlopen). However, it looks like it only happens when an older
> binutils e.g. 184.108.40.206.2 is used to build glibc.
> Adhemerval says that 220.127.116.1130531 doesn't have the problem
> with the IFUNC's OPD having a zero TOC.
> Any idea what patch fixed this?
Possibly my 2013-03-28 patches that sort ifunc relocs in .rela.dyn
after other relocs, but that doesn't seem likely since opd relocs are
relative and so sort early anyway. Have a look at .rela.dyn in your
shared library to see whether the ifunc might be called before the opd
reloc for the ifunc is applied .
Australia Development Lab, IBM