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] |
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?
Attachment:
a.out
Description: Binary data
Attachment:
libx.so
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |