+2018-02-03 Nick Clifton <nickc@redhat.com>
+
+ PR 22762
+ * scripttempl/pe.sc: Remove PROVIDE()s from __CTOR_LIST__ and
+ __DTOR_LIST__ symbols. Add a comment explaining why this is
+ necessary.
+ * scripttemp/pep.sc: Likewise.
+ * ld.texinfo (PROVIDE): Add a note about the effect of common
+ symbols.
+
2018-02-03 Sandra Loosemore <sandra@codesourcery.com>
* emulparams/nios2elf.sh (GENERATE_SHLIB_SCRIPT): Don't set.
If the program references @samp{etext} but does not define it, the
linker will use the definition in the linker script.
+Note - the @code{PROVIDE} directive considers a common symbol to be
+defined, even though such a symbol could be combined with the symbol
+that the @code{PROVIDE} would create. This is particularly important
+when considering constructor and destructor list symbols such as
+@samp{__CTOR_LIST__} as these are often defined as common symbols.
+
@node PROVIDE_HIDDEN
@subsection PROVIDE_HIDDEN
@cindex PROVIDE_HIDDEN
${RELOCATING+*(.glue_7t)}
${RELOCATING+*(.glue_7)}
${CONSTRUCTING+
- PROVIDE(___CTOR_LIST__ = .);
- PROVIDE(__CTOR_LIST__ = .);
+ /* Note: we always define __CTOR_LIST__ and ___CTOR_LIST__ here,
+ we do not PROVIDE them. This is because the ctors.o startup
+ code in libgcc defines them as common symbols, with the
+ expectation that they will be overridden by the definitions
+ here. If we PROVIDE the symbols then they will not be
+ overridden and global constructors will not be run.
+
+ This does mean that it is not possible for a user to define
+ their own __CTOR_LIST__ and __DTOR_LIST__ symbols. If that
+ ability is needed a custom linker script will have to be
+ used. (The custom script can just be a copy of this script
+ with the PROVIDE() qualifiers added).
+
+ See PR 22762 for more details. */
+ ___CTOR_LIST__ = .;
+ __CTOR_LIST__ = .;
LONG (-1);
KEEP(*(.ctors));
KEEP(*(.ctor));
LONG (0);
}
${CONSTRUCTING+
- PROVIDE(___DTOR_LIST__ = .);
- PROVIDE(__DTOR_LIST__ = .);
+ /* See comment about __CTOR_LIST__ above. The same reasoning
+ applies here too. */
+ ___DTOR_LIST__ = .;
+ __DTOR_LIST__ = .;
LONG (-1);
KEEP(*(.dtors));
KEEP(*(.dtor));
${RELOCATING+*(.glue_7)}
${CONSTRUCTING+. = ALIGN(8);}
${CONSTRUCTING+
- PROVIDE(___CTOR_LIST__ = .);
- PROVIDE(__CTOR_LIST__ = .);
+ /* Note: we always define __CTOR_LIST__ and ___CTOR_LIST__ here,
+ we do not PROVIDE them. This is because the ctors.o startup
+ code in libgcc defines them as common symbols, with the
+ expectation that they will be overridden by the definitions
+ here. If we PROVIDE the symbols then they will not be
+ overridden and global constructors will not be run.
+
+ This does mean that it is not possible for a user to define
+ their own __CTOR_LIST__ and __DTOR_LIST__ symbols. If that
+ ability is needed a custom linker script will have to be
+ used. (The custom script can just be a copy of this script
+ with the PROVIDE() qualifiers added).
+
+ See PR 22762 for more details. */
+ ___CTOR_LIST__ = .;
+ __CTOR_LIST__ = .;
LONG (-1); LONG (-1);
KEEP (*(.ctors));
KEEP (*(.ctor));
LONG (0); LONG (0);
}
${CONSTRUCTING+
- PROVIDE(___DTOR_LIST__ = .);
- PROVIDE(__DTOR_LIST__ = .);
+ /* See comment about __CTOR_LIST__ above. The same reasoning
+ applies here too. */
+ ___DTOR_LIST__ = .;
+ __DTOR_LIST__ = .;
LONG (-1); LONG (-1);
KEEP (*(.dtors));
KEEP (*(.dtor));