https://sourceware.org/bugzilla/show_bug.cgi?id=19368
--- Comment #3 from Jiong Wang <jiwang at gcc dot gnu.org> --- This is caused by the following commit which turn on elf_backend_extern_protected_data. commit b68a20d6675f1360ea4db50a9835c073675b9889 Author: Szabolcs Nagy <szabolcs.n...@arm.com> Date: Mon Jul 27 11:45:27 2015 +0100 [ARM] Fix extern protected data handling after this change we are turning on PC relocative relocation to absolute relocation, and thus the following relocation entries change: --- dump.a.right 2015-12-16 16:13:01.797125100 +0000 +++ dump.a.wrong 2015-12-16 16:10:06.045693098 +0000 Relocation section '.rel.dyn' at offset 0x4e4 contains 16 entries: Offset Info Type Sym. Value Symbol's Name ... -00011030 00000017 R_ARM_RELATIVE 0001104c 00000017 R_ARM_RELATIVE 00011018 000000a0 R_ARM_IRELATIVE 0001101c 000000a0 R_ARM_IRELATIVE @@ -115,6 +114,7 @@ 00011024 00000415 R_ARM_GLOB_DAT 00000000 __cxa_finalize 00011028 00000515 R_ARM_GLOB_DAT 00000000 _ITM_registerTMCloneTable 0001102c 00000615 R_ARM_GLOB_DAT 00000000 ret_foo +00011030 00001315 R_ARM_GLOB_DAT 00011050 global ... These runtime relocation types change looks ok to me, but their runtime resolve order will cause problem for ifunc resolver. You can see "global" is turned from RELATIVE which is resolved before IRELATIVE, into GLOBA_DAT which will be resolved after the IRELATIVE, while "global" is referenced in the ifunc function, so that ifunc function will get uninitialized address zero, then trigger segment fault. I think ARM backend need the similar fix from: https://sourceware.org/bugzilla/show_bug.cgi?id=13302 we need to make sure IRELATIVE relocation happen last. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
