Method for efficient external reference resolution in dynamically linked shared code libraries in single address space operating systems

Abstract

A system and method for resolving external references in single address space operating systems using client context based external reference resolution. The source code of a shared library module is analyzed during compilation and external references (exported variables and functions) identified. The compiler adds code to resolve the external reference based on a Global Offset Table (GOT) for each client instance of that library. The client instance maintains a global context area address register (GCR) that is combined with a library module offset value to define a real address in the single address space. Only the offset resolution code is fixed by the loader at load-time. The remaining module code is unchanged by the loader. The loader constructs a global context area for each client process as it is loaded and loads the address of that area into the Global Context Register for that process.

Claims

I claim:

1. A computer implemented method for determining a memory address of a library element in one of a plurality of shared libraries external to a client program executing in one of a plurality of processes, wherein each process references a plurality of shared libraries and said plurality of processes are executing in an operating system that manages memory as a single address space memory, the method comprising the steps of:

building at process load time a separate global offset table context area at an address for each said process as it is being loaded for execution;

storing the address of said global offset table context area at a first storage location;

for each process, assigning a client global offset table area at a storage address for each of said plurality of shared libraries containing a library element referenced by said process and storing the client global offset table area storage address at a library offset in said global offset table context area, said library offset remain constant for all processes.

2. The method of claim 1, further comprising the steps of;

resolving a reference from an executing process to a shared library element by determining a client global offset table address from said first storage location and said library offset for the referenced library; and

locating the address of said referenced library element in said client global offset table area.

3. The method of claim 2, wherein the step of resolving a reference from an executing process to a shared library element comprises the steps of:

retrieving said global offset table context area storage address from said first storage location; and

retrieving the client global offset table area address at said library offset into said global offset table context area.

4. A computer program product having a computer readable medium having computer program logic recorded thereon for resolving references from an executing process to a library element in one of a plurality of shared libraries in a computer system in which memory is managed as a single address space, said computer program product comprising:

computer program product means for causing a computer system to build at process load time a separate global offset table context area at an address for each of a plurality of processes as it is being loaded for execution;

computer program product means for causing a computer system to store said address of the global offset table context area at a first storage location;

computer program product means for causing a computer system to assign a client global offset table area for each process at a storage address for each of said plurality of shared libraries containing a library element referenced by said process and storing the client global offset table area storage address at a library offset in said global offset table context area, said library offset remaining constant for all processes.

5. The computer program product of claim 4, further comprising:

computer program product means for causing a computer system to resolve a reference from an executing process to a shared library element by determining a client global offset table address from said first storage location and said library offset for the referenced library; and

computer program product means for causing a computer system to locate the address of said referenced library element in said client global offset table area.

6. The computer program product of claim 5, wherein the computer program product means causing a computer system to resolve a reference from an executing process to a shared library element comprises:

computer program product means for causing a computer system to retrieve said global offset table context area storage address from said first storage location; and

computer program product means for causing a computer system to retrieve said client global offset table area storage address at said library offset into said global offset table context area.

7. A system for resolving references from an executing process to a library element in one of a plurality of shared libraries, said process executing in a single address space computer system, the system comprising:

means for constructing a separate global offset table context area for each client process when said process is loaded for execution;

means for allocating at a storage address a client process global offset table data storage area for each shared library containing a library element referenced by said client process, said storage address being stored in said global offset table context area at a library offset; and

means for locating a shared library element referenced by a client process by locating said global offset table context area for said client process and said global offset table address for said shared library.

8. The system of claim 7, wherein the means for locating a shared library element includes:

means for branching to a global offset table address calculation routine; and

means for calculating said global offset table address from a global offset table context area address and said library offset into said global context area.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present invention is related to the applications entitled "Method for Generating an Shared Library Executable Code with Lazy Global Offset Table Address Calculation" and "Method for Eliminating Intra-Module Global Offset Table Address Computation" filed on Dec. 14, 1995 and bearing attorney docket numbers AT995-029 and AT995-030, respectively.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to compiler technology for compiling source code programs in to programs executable on a computer system. More particularly, the present invention relates to systems and methods for causing a compiler to create executable code that efficiently resolves external data reference addresses in a shared code library.

2. Background and Related Art

Computer systems such as the IBM Risc System/6000 are able to run a large number of programs concurrently. System efficiency is improved by using libraries of shared program code that are shared by all executing programs. Shared libraries eliminate the need to include the library code in each executable program thereby reducing the size of the executable programs. Shared libraries improve memory efficiency by allowing a single copy of the library to be present in system memory rather than requiring a copy to be present for each application program that uses it.

Dynamically linked libraries are linked at run time by the application program. Each library makes certain functions and variable values available for use by application programs. These functions and values are called exported functions and exported variables of the library. At application compile time, therefore, the external references to the exported library variables are not known. The system must provide a mechanism for the application to resolve external references at run-time. Resolution of a reference is the process of determining a memory address for a referenced variable or function. The memory address allows the program to access that variable data stored at that address or to invoke the function stored at that address.

Shared libraries provide memory position independent pure code, i.e. the code of the library is not modified to account for actual loaded memory location when the library is loaded for execution. The external reference address resolution mechanism must be able to provide an address without requiring load-time modification of the base library code.

Prior art systems have solved this problem in several ways. The AIX operating system creates an exported variable table of contents (TOC) for each shared library. The TOC maps the external references of a library to memory locations. The AIX TOC for a library is adjusted at runtime to reflect the actual memory location of the library. The AIX compiler builds the TOC when the library source code is compiled.

All references to an exported variable or exported function in AIX require indirect access through the TOC. Indirect references are slower than direct references and can adversely impact performance. In addition, the TOC must always be available to the calling program. A register (typically R2) is dedicated to point to the address of the TOC by convention. The programs must always ensure that the designated register points to the correct TOC, i.e. the TOC for the library function to be accessed. The register must be modified each time a different library is accessed. All function calls in such a system are indirect. The function call first accesses a function description table (FDT). The function description table sets the designated register (e.g. R2) to point to the correct TOC and then accesses the requested function.

The disadvantage of the TOC approach is that most of the code in a program does not require external reference resolution. The TOC architecture, however, requires all references to be through the TOC whether or not they are external to the function. Thus, internal references to the exported variables are slowed by the requirement of indirect reference through the TOC.

The Sun Microsystems Solaris operating system solved the external reference problem in a different way. The Solaris operating system uses a Global Offset Table (GOT) to resolve references. The GOT is created by the compiler at a predetermined location within each library. The location is established so that the program can calculate the location of the GOT at any time thus eliminating the need to provide a register pointing to the GOT table. The GOT is placed by the compiler at the end of the library code. The program can then determine the relative location by determining where the end of the code is relative to the current position.

A shared library has the advantage that only one copy of the library code needs to be present in the computer system memory even though several programs are using that code. Multiple client programs can access the library through function calls. Each client program, however, will require an area to store its own values for the library program exported variables. For example, a shared library may have the following code segment written in C:

    ______________________________________
               int x:
               int doSomething( ) {
                 if (x== 10)
                   . . .
                 } else {
                   . . .
                 }
               }
    ______________________________________

    ______________________________________
    foo:
    . . .
    b1    find.sub.-- got31  # load my GOT pointer into R31
    . . .
    ______________________________________

    ______________________________________
    find.sub.-- got 31:
              # one in each module
    1     r31,my.sub.-- offset(GCR)
                        # fixed by the loader
    br
    ______________________________________

• Inventors
  Gheith, Ahmed Mohammed;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Jun-30-1998
• Current US Classes:
  719/331
• Application #
  572470
• International Classes
  G06F 009/42
• Field of Search
  395/685 395/710 911/200-209
• Examiner
  Oberley; Alvin E.
• Agent
  Walker; Mark S.
• US Patent References:
  4024504
  5369766
  5375241
  5475840
  5613120