This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: Zack Weinberg <zackw at panix dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Andreas Schwab <schwab at linux-m68k dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 11 Aug 2015 19:39:35 +0300 (MSK)
- Subject: Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.
- Authentication-results: sourceware.org; auth=none
- References: <55C76FCD dot 5020607 at panix dot com> <CAMe9rOoAWjRma_mG_FazVh3FGOyiGJ=g82=bsfGqa-COnt5p1g at mail dot gmail dot com> <55C78525 dot 40402 at panix dot com> <CAMe9rOrKg8nzB67+OCXz5n1u7ZLnJncpX7J6KkEXqe0Bra843w at mail dot gmail dot com> <55C79AD8 dot 3070301 at panix dot com> <20150810030920 dot GE23550 at vapier> <20150810211200 dot GA17734 at domone> <CAKCAbMia4RCA7X0YHYeXC6eAGCxzDqhWrMiGS4NxA-cDxFioVw at mail dot gmail dot com> <20150811080451 dot GA6280 at domone> <alpine dot LNX dot 2 dot 20 dot 1508111308290 dot 29573 at monopod dot intra dot ispras dot ru> <20150811104935 dot GA2713 at domone>
On Tue, 11 Aug 2015, OndÅej BÃlka wrote:
> On Tue, Aug 11, 2015 at 01:10:36PM +0300, Alexander Monakov wrote:
> > On Tue, 11 Aug 2015, OndÅej BÃlka wrote:
> > > > If not, how can we be obeying the C standard's rules about function
> > > > pointer equality?
> > > >
> > > Simple, we return null. Following causes segmentation fault.
> > >
> > > gcc -fPIC -shared x.c -o libx.so
> > > void foo (int x) __attribute__ ((ifunc ("resolve_foo")));
> > >
> > > int foo_impl(int x)
> > > {
> > > return 42;
> > > }
> > > int bar()
> > > {
> > > foo(5);
> > > void (*f)(int) = foo;
> > > f(42);
> > > }
> > >
> > >
> > > static void (*resolve_foo (void)) (void)
> > > {
> > > // printf("ifunc\n");
> > > return foo_impl; // we'll just always select this routine
> > > }
> > > gcc main.c -L. -lx
> > > void bar();
> > > int main()
> > > {
> > > bar();
> > > }
> >
> > This testcase does not segfault on glibc 2.20. Perhaps old glibc that you're
> > running did not process data relocations to ifunc symbols (as opposed to
> > jump_slot relocations). But anyway I don't see how the testcase is related to
> > what Zack was asking.
> >
> Well I wanted to explain on assembly dump how function pointers are handled but got
> segfault instead.
>
> This is weird as I use debian 2.19 and couldn't find patch that fixes
> it. Could you run attached binary from my gcc to eliminate case that gcc
> optimized function pointer away?
It segfaults. Therefore I take back my proposition that it's due to glibc
changes; rather, I did not get a segfault previously because my system uses
Gold linker by default; if I use the BFD linker instead, I do get a segfault.
My explanation is that two linkers differ in how GLOB_DAT relocation to 'foo'
is placed in .rela.dyn section. With Gold, it goes after relocation to
'foo_impl', but with ld.bfd it goes before. Therefore if the dynamic linker
processes the relocations in order, foo_impl is still 0 when foo is relocated.
That sounds like a binutils bug.
(we're going off on a tangent here, but at least we learned about an issue
with ifunc implementation)
Alexander