end(3C)

NAME
     end, etext, edata, _end, _etext, _edata, eprol, _ftext, _fdata, _fbss,
     _rt_symbol_table, _rt_symbol_table_size, _rt_symbol_string_table,
     _procedure_table, _procedure_table_size, _procedure_string_table,
     _DYNAMIC, _DYNAMIC_LNK, _DYNAMIC_LINKING, _BASE_ADDRESS, _GOT_OFFSET,
     _gp, _gp_disp, __rld_obj_head, _rld_new_interface, __elf_header,
     __program_header_table, __dso_displacement, _lib_version,
     __lcldta_address, __lcldta_size, - loader defined symbols in a program

SYNOPSIS
     extern int end[];
     extern int _end[];
     extern int etext[];
     extern int _etext[];
     extern int edata[];
     extern int _edata[];
     extern int eprol[];
     extern int _ftext[];
     extern int _fdata[];
     extern int _fbss[];
     extern int _procedure_table[];
     extern int _procedure_table_size[];
     extern int _procedure_string_table[];
     extern SYMR _rt_symbol_table[];
     extern char _rt_symbol_table_size[];
     extern char _rt_symbol_string_table[];
     extern int _gp[];
     extern int _gp_disp[];
     extern int _DYNAMIC[];
     extern int _DYNAMIC_LINK[];
     extern int _DYNAMIC_LINKING[];
     extern int _BASE_ADDRESS[];
     extern int _GOT_OFFSET[];
     extern int __rld_obj_head[];
     extern int _rld_new_interface[];
     extern int __elf_header[];
     extern int __program_header_table[];
     extern int __dso_displacement[];
     extern int _lib_version[];
     extern int __lcldta_address[];
     extern int __lcldta_size[];

DESCRIPTION
     For the convenience of utilities and other applications which need to
     access an executable in special ways, ld(1) may create one or more of the
     special symbols in the list above. Of these, only the symbols
     _procedure_table _procedure_string_table, _rt_symbol_table and
     _rt_symbol_string_table, __rld_obj_head, __elf_header,
     __program_header_table, _lib_version, which are described below, actually
     have associated data, which is specially created by ld(1).  For each of
     the remaining special symbols in the list above, no actual data is
     associated; only the address of the symbol is meaningful.  Ld(1) sets the
     symbol's address to either the location of a particular portion of the
     executable (e.g., _etext, or _edata) or to the value of some other
     interesting parameter (e.g., _procedure_table_size).

     NOTE: In order to avoid their interpretation as gp-relative data, each of
     these symbols must be declared as an array.  Moreover, most of these
     arrays are declared to have elements of type int though one must not
     conclude that this imposes any restrictions on the alignment of the
     addresses.

     The symbol versions without a leading underbar may be overridden by
     applications.  If the application defines the symbol the symbol is no
     longer special and the information here is irrelevant for the symbol.

     IMPORTANT NOTE:  many of the symbols mentioned here are release-specific
     and may change meanings or disappear across releases.

     The address of etext and _etext are the first address above the text
     segment, edata and _edata are the first address above the initialized
     data region, and end and _end are the first address above the
     uninitialized data region.

     The address of _ftext is the first address in the program text, _fdata is
     the first address in the initialized data region, and _fbss is the first
     address in the uninitialized data region.

     Note that the _ftext, _etext, _edata, _ftext, _fdata, and _fbss are
     rather questionable things to depend on for programs using dso's or
     having multiple text or data regions.  There is no standard definition of
     the meanings of these symbols when there are multiple text or data
     regions present.  For example, use of ld options and spec files can
     result in the creation of multiple text and/or data regions.  Most
     programs use dso's and that means there are multiple text, data, and bss
     regions in the running application.  Instead of presuming that these
     symbols mean something specific, applications would be better off using
     __elf_header and __program_header_table and __dso_displacement to
     determine the memory regions of whatever code refers to the symbol. That
     is,  from within a dso (or main program), __elf_header refers to the
     __elf_header of that dso (or main program).  One can use dlopen and dlsym
     to access the symbols of a different dso or, from a dso, of the main
     program (see the dlopen man page).

     eprol is a symbol that was once used by libprof but is no longer used.
     User code may freely define its own such symbol for any application
     purpose.

     In ISO/ANSI C the symbols end, edata, and etext are elements of the space
     of names reserved for the user.  Thus, by default these symbols are not
     defined by the loader (ld(1)). If, however, a reference to end, edata, or
     etext is unsatisfied during the link, it will be defined by the loader.
     The address of the resultant symbol will be identical to the address of
     the symbol of the same name prefixed by an underbar. (Thus, if an
     unsatisfied reference to end remains at the end of the link, ld(1) will
     satisfy the reference by giving it the same address as _end, which is
     always defined.)

     Some symbols have a dso-specific specific meaning. That is, a query of
     the value within a dso can get a dso-specific value:  the values are not
     global, but specific to the main program or dso taking the address of the
     symbol.  The dso-specific symbols are:  _gp, _gp_disp, _procedure_table,
     _procedure_table_size, _procedure_string_table, _rt_symbol_table,
     _rt_symbol_table_size, _rt_symbol_string_table, _data_init_table,
     _DYNAMIC_LINK, _DYNAMIC_LINKING, and _BASE_ADDRESS.  All the other
     symbols are global and therefore a single value (that of the main
     program) will be seen from all dsos and the main program because of the
     global symbol resolution rules.

     All of the symbols beginning with _ (underbar) are reserved to the
     implementation by ISO/ANSI C rules and it is unwise to attempt to define
     these as global symbols.

     _gp is the address of the region of global data accessed by offsets of
     the global-pointer register (ie, its address is the run-time value of the
     global-pointer register.)

     _gp_disp has the same value as _gp.

     When execution begins, the program break coincides with _end, but it is
     reset by the routines brk(2), malloc(3), standard input/output
     (stdio(3)), the profile (-p) option of cc(1), etc.  The current value of
     the program break is reliably returned by `sbrk(0)', see brk(2).

     _DYNAMIC_LINKING and _DYNAMIC_LINK are identical. If referred to, they
     have special value generated by the linker:  0 means this code is non-
     shared, 1 means the code is in a KPIC executable, and 2 means the code is
     in a dso.

     _DYNAMIC is a symbol which is no longer used.

     _BASE_ADDRESS is the virtual address of the first loadable segment in the
     dso/executable.

     _GOT_OFFSET is no longer used or set.

     __rld_obj_head is set to the virtual address of a pointer to the list of
     dso's in a 32-bit executable.  See also <obj.h> and <obj_list.h> and
     rld(1).

     _rld_new_interface is set to the address of a function within rld that
     implements various run-time linking facilities.  See rld for further
     information.

     __elf_header is set to point to the elf header of the executing object or
     dso.

     __program_header_table is set to point to the program header table of the
     executing object or dso.

     __dso_displacement is set to point to a 32-bit word (in a 32-bit program)
     which is the amount the executable or dso has been moved by rld at run-
     time.

     _lib_version is set to point to the address of a 32-bit integer.  The
     value of the integer is 0 normally.  It can be non-zero with applications
     linked -abi and -cckr which can affect slightly the behavior of abi
     applications calling scanf, ldexp, or atof.

     __lcldta_address is set to the address of a special section used to keep
     thread-local data for MP programming. See the MP documentation for
     further information.  This symbol is not applicable to applications
     compiled as 64-bit programs.

     __lcldta_size is set to the size (in bytes) of the special section
     referred to above.  This symbol is not applicable to applications
     compiled as 64-bit programs.

     The loader defined symbols _procedure_table, _procedure_table_size, and
     _procedure_string_table refer to data structures of the runtime procedure
     table.  The procedure table data structures are built by ld(1) only if
     they are referenced.  See the include file <sym.h> for the definition of
     the runtime procedure table and see the include file <exception.h> for
     its uses.  These symbols are not applicable to applications compiled as
     64-bit programs.

     The loader defined symbols _rt_symbol_table, _rt_symbol_table_size, and
     _rt_symbol_string_table refer to data structures of the runtime symbol
     table.  The runtime symbol table structures are built by ld(1) only if
     they are referenced. The runtime symbol table includes all stProc and
     stGlobal symbols and is used by the kernel for dynamically loadable
     kernel modules.  See the include file <sym.h> for the definition of the
     runtime symbol table.  These symbols are not applicable to applications
     compiled as 64-bit programs.

SEE ALSO
     brk(2), malloc(3c), ld(1), cc(1), f77(1), pc(1), mload(4), rld(1)