compiler_eoe Release Notes
1 Introduction
A Dynamic Shared Objects
- 1 -
1. Introduction
These notes describe the IRIX Compiler Execution Environment
(compiler_eoe) from Silicon Graphics, Inc. The IRIX
Compiler EOE contains compiler execution utilites such as
rld and those base compiler libraries supplied as DSOs
(dynamic shared objects). DSOs are discussed in Appendix A
and in the dso(5) man page.
Note: Packaged with this software is a separate sheet that
contains the Software License Agreement. This
software is provided to you solely under the terms
and conditions of the Software License Agreement.
Please take a few moments to review the Agreement.
1.1 System_Prerequisite
If you plan to run any IRIX applications, it is important to
note that you must install the IRIX Compiler EOE.
1.2 Release_Identification_Information
Following is the release identification information for the
IRIX Compiler Execution Environment (compiler_eoe):
Software Product Compiler_eoe
Version 3.18
System Software Requirements IRIX 5.2
1.3 3.18_IRIX_Compiler_Execution_Environment_Subsystems
The 3.18 IRIX Compiler EOE software (compiler_eoe) includes
these subsystems:
compiler_eoe IRIX compiler execution
environment
compiler_eoe.man IRIX compiler execution
environment man pages
compiler_eoe.man.dso IRIX DSO man page
compiler_eoe.man.unix IRIX compiler man pages
compiler_eoe.sw IRIX compiler execution
environment software
- 2 -
compiler_eoe.sw.cpp Source code preprocessor
compiler_eoe.sw.lboot Kernel lboot software
compiler_eoe.sw.lib Base compilers execution
libraries
compiler_eoe.unix IRIX execution environment
(compiler)
1.4 Online_Release_Notes
After you install the online documentation for a product
(the relnotes subsystem), you can view the release notes on
your screen.
If you have a graphics system, select ``Release Notes'' from
the Tools submenu of the Toolchest. This displays the
grelnotes(1) graphical browser for the online release notes.
Refer to the grelnotes(1) man page for information on
options to this command.
If you have a nongraphics system, you can use the relnotes
command. Refer to the relnotes(1) man page for accessing
the online release notes.
1.5 Product_Support
Silicon Graphics, Inc., provides a comprehensive product
support maintenance program for its products.
If you are in the U.S. or Canada and would like support for
your Silicon Graphics-supported products, contact the
Technical Assistance Center at 1-800-800-4SGI. If you are
outside these areas, contact the Silicon Graphics subsidiary
or authorized distributor in your country.
- 1 -
1. Dynamic_Shared_Objects
A Dynamic Shared Object, or DSO, is an ELF format object
file, very similar in structure to an executable program but
with no "main". It has a shared component, consisting of
shared text and read-only data; a private component,
consisting of data and the GOT (Global Offset Table);
several sections that hold information necessary to load and
link the object; and a liblist, the list of other shared
objects referenced by this object. Most of the libraries
supplied by SGI are available as dynamic shared objects.
A DSO is relocatable at runtime; it can be loaded at any
virtual address. A consequence of this is that all
references to external symbols must be resolved at runtime.
References from the private region (.e.g. from private data)
are resolved once at load-time; references from the shared
region (e.g. from shared text) must go through an
indirection table (GOT) and hence have a small performance
penalty associated with them.
Code compiled for use in a shared object is referred to as
Position Independent Code (PIC), whereas non-PIC is usually
referred to as non-shared. Non-shared code and PIC cannot
be mixed in the same object.
At Runtime, exec loads the main program and then loads rld,
the runtime linking loader, which finishes the exec
operation. Starting with main's liblist, rld loads each
shared object on the list, reads that object's liblist, and
repeats the operation until all shared objects have been
loaded. Next, rld allocates common and fixes up symbolic
references in each loaded object. (This is necessary
because we don't know until runtime where the object will be
loaded.) Next, each object's init code is executed.
Finally, control is transferred to "__start".
For a more complete discussion of DSOs, including answers to
questions frequently asked about them, see the dso(5) man
page.