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: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.


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

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