Created attachment 8784 [details] 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.
Created attachment 8786 [details] updated patch to add testcases Sorry, that patch was not quite right. Here is a corrected one.