Remove PROVIDE() qualifiers from definition of __CTOR_LIST__ and __DTOR_LIST__ symbols in PE linker scripts.

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.
This commit is contained in:
Nick Clifton 2018-02-03 13:11:35 +00:00
parent 138a158f0a
commit b0daac83d7
4 changed files with 56 additions and 8 deletions

View File

@ -1,3 +1,13 @@
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.

View File

@ -4001,6 +4001,12 @@ underscore), the linker will silently use the definition in the program.
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

View File

@ -98,8 +98,22 @@ SECTIONS
${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));
@ -107,8 +121,10 @@ SECTIONS
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));

View File

@ -99,8 +99,22 @@ SECTIONS
${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));
@ -108,8 +122,10 @@ SECTIONS
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));