IRIX 6.5  »  Man Pages
find in page

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 that need to
     access an executable in special ways, ld(1) may create one or more of
     the special symbols listed in the SYNOPSIS.  Of these, only the
     symbols _procedure_table _procedure_string_table, _rt_symbol_table,
     _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 listed in the SYNOPSIS, 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 (such as _etext, or _edata) or
     to the value of some other interesting parameter (such as
     _procedure_table_size).

     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 do 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.

     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.

     _ftext, _etext, _edata, _ftext, _fdata, and _fbss are questionable to
     depend on for programs using DSOs 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 DSOs 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).  You 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 end, edata, and etext symbols 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 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 you should not 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 (its address is the run-time value of
       the global-pointer register.)

     * _gp_disp has the same value as _gp.

     * _end marks the next address after the segment with the highest
       virtual address. Usually this is right after the BSS, but may not be
       if the user specifically changes the default segment layout.

       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 DSOs 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 <sym.h> include
       file for the definition of the runtime symbol table.  These symbols
       are not applicable to applications compiled as 64-bit programs.

 SEE ALSO

     ld(1), cc(1), f77(1), pc(1), rld(1)

     brk(2)

     malloc(3C)

     mload(4)