[PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.

[Ondřej Bílka]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.out
Type: application/octet-stream
Size: 7024 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150811/28dceeb3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libx.so
Type: application/octet-stream
Size: 6464 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150811/28dceeb3/attachment.so>