Abstract:
A dynamic linking loader is provided for a pre-operating-system environment. Such a loader can provide a simple, flexible, and cost effective way for loading modules at run time in a pre-operating-system environment.

Description:
BACKGROUND  
       [0001]     Before a manufacturer installs an operating system on a computer system, typically it tests and verifies the operation of both the hardware and firmware.  
         [0002]     Pre-Operating System Environments—For many computer systems with Intel central processing units, the pre-operating system verification environment is the extensible firmware interface (EFI). The EFI environment is typically used with verification tools to test interactions between chipsets, system busses, I/O busses, peripherals, system firmware and other system level entities. EFI is an industry standard and applies to all IPF systems. Specifically, the EFI firmware interfaces with the System Abstraction Layer (SAL), which in turn interfaces with the Processor Abstraction Layer (PAL), which interfaces with a hardware IPF processor.  
         [0003]     The EFI environment manages a computer system&#39;s memory until an operating system is booted. Pre-operating system verification applications can be run both inside of EFI (EFI applications) and on top of EFI (non-EFI applications) as part of the EFI environment utilizing the EFI library of functions such as the real time clock and tables of EFI parameters and variable names. The EFI library is also accessible by the operating system after it is booted.  
         [0004]     Compilation—Computers typically execute low-level machine languages that are easily processed by computer processors but that are difficult and time consuming for programmers to use, whereas programming is typically done in a high level language that is easier and less time consuming for programmers to use. A compiler is a translator whose source language is a high-level language and whose object language is close to the machine language of an actual computer, either being an assembly language or some variety of machine language (relocatable or absolute). Translation of a high-level source language into executable machine language programs often involves more than one translation step. For example, it is not uncommon to have a program first compiled into a machine-dependent assembly language, then assembled to produce relocatable machine code, and finally loaded and linked to produce executable machine code. Moreover, the compilation step itself typically involves a number of passes that progressively translate the program into various intermediate forms before producing the final object program.  
         [0005]     Loaders—A loader, or linking loader, is a translator step whose object language is the actual executable machine code, and whose source language is almost identical, but usually consists of machine language programs in relocatable form together with tables of data specifying points where the relocatable code must be modified to become truly executable. This step is performed just prior to execution after actual memory has been allocated.  
         [0006]     Libraries—A scope is typically classified as dynamic or static. A dynamic scope rule defines a scope in terms of program execution at run time. A static scope rule defines a scope in terms of the structure of the program at build time (translation time). Programs typically contain function calls to modules in a library that is available to the compiler. In a static library environment, the modules referenced by the program function calls are linked and loaded at build time and cannot be changed at run time. In a dynamic environment, the library is available at run time and the linking and loading of the library modules is done just prior to initialization of execution.  
         [0007]     References—Referencing is the operation of retrieving the data or program object currently associated with a given identifier using the unique currently active association for the identifier. References to identifiers are classified as local references if they use an association active only within the subprogram currently being executed. A global reference is a reference to an association active throughout program execution. A local environment or local referencing environment is used to designate those local associations introduced at the last change in the referencing environment.  
         [0008]     The above-described concepts are discussed and illustrated below in conjunction with  FIGS. 1A-3 .  
         [0009]     Referring to  FIG. 1A , a static pre-operating system build time environment  10  is shown that includes an EFI application  2  and a non-EFI application  4 , both of which include function calls to EFI library module  8 . The library module  8  is in the form of relocatable machine code with a table of data specifying points where the relocatable code must be modified to become truly executable machine code. The static pre-operating system build time environment  10  includes a static loader  6 . During the final step of the compilation of the application  2 , the static loader  6  links a first copy of the module  8  to the application  2  and modifies all of the places where a relative address needs to be replaced with an absolute address. In a similar manner, during the final step of the compilation of the non-EFI application  4 , the static loader  6  links a second copy of the module  8  to the application  4  and modifies all of the places where a relative address needs to be replaced with an absolute address. In such a static pre-operating system build time environment, each function call in each application  2  and  4  requires a copy of the relocatable library module  8 . Any change to the source code in the applications  2  and  4  or the called module  8  requires a complete recompilation of the applications.  
         [0010]     Referring to  FIG. 1B , the static pre-operating system run time environment  12  associated with the static pre-operating build environment  10  ( FIG. 1A ) no longer has access to a loader. The compiled EFI application  2  linked to the compiled EFI library module  8  is in non-relocatable machine code format and is loaded into memory to be executed.  
         [0011]      FIG. 1C  shows the static pre-operating system run time environment  12  associated with the static pre-operating build environment  10  during execution. The compiled application  2  contains function calls  14  which are satisfied by the compiled and linked copy of EFI module  8 . The variables inside of the library module  8  with global references have access to all the variables associated with the compiled application  2 . The reference environment is static and is set at build time and cannot be changed without a recompilation. Also, if there is any change in the code for application  2  the entire package needs to be recompiled, and if there is any change in the code for module  8 , the entire package needs to be recompiled. Therefore, if there is any additional required functionality, the functionality has to be added in a static pre-operating build environment and the entire package needs to be recompiled.  
         [0012]     Referring to  FIG. 2A , a static pre-operating system build time environment  20  includes of a number (here four) of applications AA-DD, some of which are EFI applications and some of which are non-EFI applications, and all of which require functionality from EFI library module NN. The static loader  6  copies module NN into each of the applications, links the relocatable machine code of the module NN to the machine code of the applications AA-DD, and produces four applications in absolute machine code format capable of being executed.  
         [0013]     Referring to  FIG. 2B , the static pre-operating system run time environment  22  associated with the static pre-operating build environment  20  ( FIG. 2A ) no longer has access to a loader. The absolute binaries of applications AA-DD can be executed. There can be no changes to the applications or the shared library module without recompiling. Also, there is no way to add or remove functionality to or from any of the applications AA-DD without a complete recompilation of the entire set.  
         [0014]     Referring to  FIG. 3 , a pre-operating system environment upgrade process  112  includes a static build time environment  112 , a static run time environment  114 , and an upgrade environment  120 . As previously described, during static build time  110 , EFI applications  100  and non-EFI applications  104  are compiled using the EFI library  102  to satisfy function call references. This is done by the static loader  106  copying modules from the EFI library  102  into the applications and linking them in an absolute machine code format. During the static run time  114 , the compiled EFI application  116  with linked library modules is executed. During the static run time  114 , the compiled non-EFI application  118  with linked library modules is also executed. If there is a code upgrade  122  to an EFI application or a non-EFI application during an upgrade time  120 , the process returns to the build time environment  110  via the path  124  and recompiles the applications. If there is a code upgrade to a referenced library module the process returns to the build time environment  110  via the path  124  and recompiles the applications after recompiling the EFI library  106  with the upgraded module. There is no means to change the static environments without starting the process over from the beginning. This is inconvenient, costly, procedurally complex, inflexible, and time intensive.  
       SUMMARY  
       [0015]     A dynamic linking loader is provided for a pre-operating-system environment.  
         [0016]     Such a loader can provide a simple, flexible, and cost effective way for loading modules at run time in a pre-operating-system environment. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0017]      FIG. 1A  (prior art) is a block diagram showing a static build time environment with a static loader.  
         [0018]      FIG. 1B  (prior art) is a block diagram of the run time environment of the applications of  FIG. 1A .  
         [0019]      FIG. 1C  (prior art) is a block diagram of the run time environment of  FIG. 1B  showing the conventional way functional calls are made and global variables are made available.  
         [0020]      FIG. 2A  (prior art) is a block diagram of a static build time environment showing several applications requiring the same library module.  
         [0021]      FIG. 2B  (prior art) is a block diagram of a static run time environment showing the several applications of  FIG. 2A  with the same library module loaded.  
         [0022]      FIG. 3  (prior art) is a functional diagram of a system-verification process with a static loader.  
         [0023]      FIG. 4A  is a block diagram showing a build time environment with a dynamic loader according to an embodiment of the invention.  
         [0024]      FIG. 4B  is a block diagram of the run time environment of the applications of  FIG. 4A  according to an embodiment of the invention.  
         [0025]      FIG. 4C  is a block diagram of the run time environment of  FIG. 4B  showing the way functional calls are made and global variables accessed according to an embodiment of the invention.  
         [0026]      FIG. 5A  is a block diagram of a build time environment showing several applications requiring the same library module according to an embodiment of the invention.  
         [0027]      FIG. 5B  is a block diagram of a run time environment of the several applications of  FIG. 5A  with the same library module loaded according to an embodiment of the invention.  
         [0028]      FIG. 5C  a block diagram of a subsequent run time environment showing the several applications of  FIG. 5A  with an upgraded library module dynamically loaded according to an embodiment of the invention.  
         [0029]      FIG. 5D  a block diagram of a subsequent run time environment showing several upgraded applications relative to  FIG. 5B  with a common library module dynamically loaded according to an embodiment of the invention.  
         [0030]      FIG. 6A  is a block diagram of a build time environment showing an application built with several different sets of library modules according to an embodiment of the invention.  
         [0031]      FIG. 6B  is a block diagram of a run time environment showing the application of  FIG. 6A  becoming several different applications based on different sets of library modules according to an embodiment of the invention.  
         [0032]      FIG. 7  is a functional diagram showing a system verification process with a dynamic loader according to an embodiment of the invention. 
     
    
     DESCRIPTION OF THE INVENTION  
       [0033]     Referring to  FIG. 4A , a dynamic pre-operating system build time environment  40  is shown that includes an EFI application  42  and a non-EFI application  44 , both of which include function calls to EFI library module  48 . The library module  48  is in the form of relocatable machine code with a table of data specifying points where the relocatable code must be modified to become truly executable machine code. The dynamic pre-operating system build time environment  40  includes a dynamic loader  46 . The dynamic loader  46  is made part of the EFI application  42  and also the non-EFI application  44 . The library module  48  is in an Application Binary Format (ABI). The ABI defined by Intel for EFI systems is ELF64. During the compilation of the EFI application  42 , a reference to the ABI conforming library module  48  is made and inserted, but not loaded. During the compilation of the non-EFI application  44 , another reference to the ABI conforming library module  48  is made and inserted, but not loaded.  
         [0034]     Referring to  FIG. 4B , the dynamic pre-operating system run time environment  49  associated with the dynamic pre-operating build environment  40  ( FIG. 4A ) includes the dynamic loader  46  as part of each application. The dynamic loader  46  is a piece of code that understands how to load a module into memory, parse the library module contents, perform the necessary relocations, and finally link any dependencies between the loading application and the module being loaded. The dynamic loader  46  links the loaded copy of the ABI conforming library module  48  to the EFI application  42  and modifies all of the places where a relative address needs to be replaced with an absolute address. In a similar manner, during the loading of the non-EFI application  44 , the dynamic loader  46  links a second loaded copy of the ABI conforming library module  48  to the non-EFI application  44  and modifies all of the places where a relative address needs to be replaced with an absolute address. The compiled EFI application  42  linked to the compiled ABI conforming EFI library module  48  is in non-relocatable machine code format and is ready to be executed. In a similar manner, the compiled non-EFI application  44  linked to the compiled ABI conforming EFI library module  48  is in non-relocatable machine code format and is ready to be executed.  
         [0035]     After the first execution of the compiled, linked and loaded applications, there can be any number of additional executions at subsequent dynamic run times. If there is an upgrade to the library module  48  and the upgraded library module is recompiled, then the upgraded ABI conforming library module  48  replaces the non-upgraded version of the module in the library, and at the next dynamic run time, the dynamic loader  46  links and loads the upgraded ABI conforming library module  48  to the referencing application without a need to recompile the application.  
         [0036]      FIG. 4C  shows the dynamic pre-operating system run time environment  49  associated with the dynamic pre-operating build environment  40  ( FIG. 4A ) during execution. The compiled application  42  contains function calls  43  which are satisfied by the compiled and linked copy of ABI conforming EFI module  48 . The variables inside of the library module  48  with global references have access to all the variables associated with the compiled application  42 . The reference environment is dynamic and is set at run time and thus can be changed without a recompilation of the application if the library is upgraded. Although the dynamic loader  46  is present during execution of the application  42 , it is not used until a subsequent loading operation preceding a subsequent execution. And although only one of the applications  42  is shown, the execution of the application  44  is similar.  
         [0037]     Referring to  FIG. 5A , a dynamic pre-operating system build time environment  50  includes a number (here four) of applications A 1 -D 1 , some of which are EFI applications and some of which are non-EFI applications, and all of which require functionality from ABI conforming EFI library module N 1 . The dynamic loader  46  is built into each application as part of the compilation process. Then the dynamic loader  46  copies ABI conforming EFI library N 1  into each of the applications.  
         [0038]     Referring to  FIG. 5B , the dynamic pre-operating system run time environment  52  associated with the dynamic pre-operating build environment  50  ( FIG. 5A ) continues to have access to the loader  46 . Each application&#39;s dynamic loader  46  links the relocatable machine code of the module N 1  to the machine code of the applications A 1 -D 1  and produces four applications in absolute machine code format capable of being executed.  
         [0039]     Referring to  FIG. 5C , a first subsequent dynamic pre-operating system run time environment  54  includes the same four applications A 1 -D 1 , each of which incorporates a dynamic loader  46  that links and loads an upgraded ABI conforming EFI library N 2  prior to execution. None of the applications need to be recompiled to change the functionality associated with the upgraded ABI conforming EFI library N 2 .  
         [0040]     Referring to  FIG. 5D , a second subsequent dynamic pre-operating system run time environment  56  includes the same four applications, but two of the applications have different additional functionality. Application A 2  is an upgrade of application A 1  ( FIG. 5B ) and application C 2  is an upgrade of application C 1  ( FIG. 5B ). These two applications are separately recompiled and when linked and loaded access the new functionality from the ABI conforming library. There is no need for a recompilation of the entire set of applications and modules.  
         [0041]     Referring to  FIG. 6A , a dynamic pre-operating system build time environment  60  includes a dynamic loader  46 , a base application E 0  capable of different functionality based on which ABI conforming library modules are referenced, and a set of ABI conforming library modules X-Z. The compiler places a copy of the dynamic loader  46  in each version of the application. The dynamic loader  46  will then copy relocatable machine code of the referenced ABI conforming library modules into the applications.  
         [0042]     Referring to  FIG. 6B , the dynamic pre-operating system run time environment  62 , which associated with the dynamic pre-operating system build time environment  60  ( FIG. 6A ) shows three different derived applications E 1 -E 3 , each with a different set of ABI conforming library modules X-Z. Application E 1  includes the functionality of module X and module Y, application E 2  includes the functionality of module Y and module Z, and application E 3  includes the functionality of module X and module Z. One can change the functionality of any of these applications E 1 -E 3  at any subsequent run time without recompiling the applications. For example, one can modify the application E 3  to also include the functionality of the module Y by having the loader  46  load the module Y at the start of a subsequent run time.  
         [0043]     Referring to  FIG. 7 , a dynamic pre-operating system environment upgrade process  200  includes a dynamic build time environment  202 , a dynamic run time environment  208 , and an upgrade environment  220 . As previously described, during dynamic build time  202 , EFI applications  204  and non-EFI applications  212  are compiled using the ABI conforming EFI library  216  to satisfy function call references. This is done by the dynamic loader  206 , which after being made part of each application by the compiler, copies modules from the EFI library  216  into the applications. During the subsequent dynamic run time  208 , the dynamic loader  206  in the compiled EFI application  210  links all referenced library modules and then is executed. Also, during the subsequent dynamic run time  208 , the dynamic loader  206  in the compiled non-EFI application  214  links all referenced library modules and then is executed. If there is a code upgrade  222  to an EFI application or a non-EFI application during an upgrade time  220 , the process returns to the build time environment  202  via the path  224  and recompiles the applications. If there is a code upgrade to a referenced library module, the process returns to the dynamic run time environment  208  via the path  226  after recompiling the upgraded ABI conforming EFI library  218  with the upgraded module, thus changing or adding functionality to the application without needing to recompile the application.  
         [0044]     The preceding discussion is presented to enable a person skilled in the art to make and use the invention. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the generic principles herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.