ld: Output Section Keywords
1
1 3.6.6 Output Section Keywords
1 -----------------------------
1
1 There are a couple of keywords which can appear as output section
1 commands.
1
1 'CREATE_OBJECT_SYMBOLS'
1 The command tells the linker to create a symbol for each input
1 file. The name of each symbol will be the name of the
1 corresponding input file. The section of each symbol will be the
1 output section in which the 'CREATE_OBJECT_SYMBOLS' command
1 appears.
1
1 This is conventional for the a.out object file format. It is not
1 normally used for any other object file format.
1
1 'CONSTRUCTORS'
1 When linking using the a.out object file format, the linker uses an
1 unusual set construct to support C++ global constructors and
1 destructors. When linking object file formats which do not support
1 arbitrary sections, such as ECOFF and XCOFF, the linker will
1 automatically recognize C++ global constructors and destructors by
1 name. For these object file formats, the 'CONSTRUCTORS' command
1 tells the linker to place constructor information in the output
1 section where the 'CONSTRUCTORS' command appears. The
1 'CONSTRUCTORS' command is ignored for other object file formats.
1
1 The symbol '__CTOR_LIST__' marks the start of the global
1 constructors, and the symbol '__CTOR_END__' marks the end.
1 Similarly, '__DTOR_LIST__' and '__DTOR_END__' mark the start and
1 end of the global destructors. The first word in the list is the
1 number of entries, followed by the address of each constructor or
1 destructor, followed by a zero word. The compiler must arrange to
1 actually run the code. For these object file formats GNU C++
1 normally calls constructors from a subroutine '__main'; a call to
1 '__main' is automatically inserted into the startup code for
1 'main'. GNU C++ normally runs destructors either by using
1 'atexit', or directly from the function 'exit'.
1
1 For object file formats such as 'COFF' or 'ELF' which support
1 arbitrary section names, GNU C++ will normally arrange to put the
1 addresses of global constructors and destructors into the '.ctors'
1 and '.dtors' sections. Placing the following sequence into your
1 linker script will build the sort of table which the GNU C++
1 runtime code expects to see.
1
1 __CTOR_LIST__ = .;
1 LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
1 *(.ctors)
1 LONG(0)
1 __CTOR_END__ = .;
1 __DTOR_LIST__ = .;
1 LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
1 *(.dtors)
1 LONG(0)
1 __DTOR_END__ = .;
1
1 If you are using the GNU C++ support for initialization priority,
1 which provides some control over the order in which global
1 constructors are run, you must sort the constructors at link time
1 to ensure that they are executed in the correct order. When using
1 the 'CONSTRUCTORS' command, use 'SORT_BY_NAME(CONSTRUCTORS)'
1 instead. When using the '.ctors' and '.dtors' sections, use
1 '*(SORT_BY_NAME(.ctors))' and '*(SORT_BY_NAME(.dtors))' instead of
1 just '*(.ctors)' and '*(.dtors)'.
1
1 Normally the compiler and linker will handle these issues
1 automatically, and you will not need to concern yourself with them.
1 However, you may need to consider this if you are using C++ and
1 writing your own linker scripts.
1