https://sourceware.org/bugzilla/show_bug.cgi?id=19251
Bug ID: 19251
Summary: Dynamic relocs for .init_array ordered wrong when
building shared libraries
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: pb at pbcl dot net
CC: ian at airs dot com
Target Milestone: ---
Created attachment 8784
--> https://sourceware.org/bugzilla/attachment.cgi?id=8784&action=edit
patch to add new testcases
Code in Sized_relobj_file::do_relocate reverses the order of the words in
.init_array in order to preserve the expected order of entries in .ctors. This
works fine when generating an executable, but it doesn't appear to make any
effort to adjust the location of the relocs that will be emitted when
generating a shared library. The consequences of this vary depending on the
exact situation:
1. If all constructors have static linkage then:
- for a REL platform, every reloc will be identical (all R_xxx_RELATIVE) and
there will be no ill effects.
- for a RELA platform, the words in .init_array will be all zeros because the
addend is in the relocation. Re-ordering .init_array will have no effect and
the constructors will run in the wrong order.
2. If all the constructions have global linkage then they will get R_386_32 or
equivalent relocs and the addends will all be zero. In this case, again,
reordering the words in .init_array will have no effect and the constructors
will run in the wrong order.
3. If the shared library contains a mix of constructors with static and dynamic
linkage then, on a REL platform, the relocs and their addends will no longer
match up and the program will almost certainly crash.
--
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
