home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 8
/
FreshFishVol8-CD2.bin
/
bbs
/
gnu
/
gcc-2.6.3-bin.lha
/
GNU
/
info
/
gcc.info-22
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1994-12-23
|
44KB
|
788 lines
This is Info file gcc.info, produced by Makeinfo-1.55 from the input
file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 675 Massachusetts Avenue
Cambridge, MA 02139 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation,
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.
File: gcc.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format
How Initialization Functions Are Handled
----------------------------------------
The compiled code for certain languages includes "constructors"
(also called "initialization routines")--functions to initialize data
in the program when the program is started. These functions need to be
called before the program is "started"--that is to say, before `main'
is called.
Compiling some languages generates "destructors" (also called
"termination routines") that should be called when the program
terminates.
To make the initialization and termination functions work, the
compiler must output something in the assembler code to cause those
functions to be called at the appropriate time. When you port the
compiler to a new system, you need to specify how to do this.
There are two major ways that GCC currently supports the execution of
initialization and termination functions. Each way has two variants.
Much of the structure is common to all four variations.
The linker must build two lists of these functions--a list of
initialization functions, called `__CTOR_LIST__', and a list of
termination functions, called `__DTOR_LIST__'.
Each list always begins with an ignored function pointer (which may
hold 0, -1, or a count of the function pointers after it, depending on
the environment). This is followed by a series of zero or more function
pointers to constructors (or destructors), followed by a function
pointer containing zero.
Depending on the operating system and its executable file format,
either `crtstuff.c' or `libgcc2.c' traverses these lists at startup
time and exit time. Constructors are called in forward order of the
list; destructors in reverse order.
The best way to handle static constructors works only for object file
formats which provide arbitrarily-named sections. A section is set
aside for a list of constructors, and another for a list of destructors.
Traditionally these are called `.ctors' and `.dtors'. Each object file
that defines an initialization function also puts a word in the
constructor section to point to that function. The linker accumulates
all these words into one contiguous `.ctors' section. Termination
functions are handled similarly.
To use this method, you need appropriate definitions of the macros
`ASM_OUTPUT_CONSTRUCTOR' and `ASM_OUTPUT_DESTRUCTOR'. Usually you can
get them by including `svr4.h'.
When arbitrary sections are available, there are two variants,
depending upon how the code in `crtstuff.c' is called. On systems that
support an "init" section which is executed at program startup, parts
of `crtstuff.c' are compiled into that section. The program is linked
by the `gcc' driver like this:
ld -o OUTPUT_FILE crtbegin.o ... crtend.o -lgcc
The head of a function (`__do_global_ctors') appears in the init
section of `crtbegin.o'; the remainder of the function appears in the
init section of `crtend.o'. The linker will pull these two parts of
the section together, making a whole function. If any of the user's
object files linked into the middle of it contribute code, then that
code will be executed as part of the body of `__do_global_ctors'.
To use this variant, you must define the `INIT_SECTION_ASM_OP' macro
properly.
If no init section is available, do not define
`INIT_SECTION_ASM_OP'. Then `__do_global_ctors' is built into the text
section like all other functions, and resides in `libgcc.a'. When GCC
compiles any function called `main', it inserts a procedure call to
`__main' as the first executable code after the function prologue. The
`__main' function, also defined in `libgcc2.c', simply calls
`__do_global_ctors'.
In file formats that don't support arbitrary sections, there are
again two variants. In the simplest variant, the GNU linker (GNU `ld')
and an `a.out' format must be used. In this case,
`ASM_OUTPUT_CONSTRUCTOR' is defined to produce a `.stabs' entry of type
`N_SETT', referencing the name `__CTOR_LIST__', and with the address of
the void function containing the initialization code as its value. The
GNU linker recognizes this as a request to add the value to a "set";
the values are accumulated, and are eventually placed in the executable
as a vector in the format described above, with a leading (ignored)
count and a trailing zero element. `ASM_OUTPUT_DESTRUCTOR' is handled
similarly. Since no init section is available, the absence of
`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main'
as above, starting the initialization process.
The last variant uses neither arbitrary sections nor the GNU linker.
This is preferable when you want to do dynamic linking and when using
file formats which the GNU linker does not support, such as `ECOFF'. In
this case, `ASM_OUTPUT_CONSTRUCTOR' does not produce an `N_SETT'
symbol; initialization and termination functions are recognized simply
by their names. This requires an extra program in the linkage step,
called `collect2'. This program pretends to be the linker, for use
with GNU CC; it does its job by running the ordinary linker, but also
arranges to include the vectors of initialization and termination
functions. These functions are called via `__main' as described above.
Choosing among these configuration options has been simplified by a
set of operating-system-dependent files in the `config' subdirectory.
These files define all of the relevant parameters. Usually it is
sufficient to include one into your specific machine-dependent
configuration file. These files are:
`aoutos.h'
For operating systems using the `a.out' format.
`next.h'
For operating systems using the `MachO' format.
`svr3.h'
For System V Release 3 and similar systems using `COFF' format.
`svr4.h'
For System V Release 4 and similar systems using `ELF' format.
`vms.h'
For the VMS operating system.
The following section describes the specific macros that control and
customize the handling of initialization and termination functions.
File: gcc.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format
Macros Controlling Initialization Routines
------------------------------------------
Here are the macros that control how the compiler handles
initialization and termination functions:
`INIT_SECTION_ASM_OP'
If defined, a C string constant for the assembler operation to
identify the following data as initialization code. If not
defined, GNU CC will assume such a section does not exist. When
you are using special sections for initialization and termination
functions, this macro also controls how `crtstuff.c' and
`libgcc2.c' arrange to run the initializati