Page #21 (Simulation Program)

< BACK  NEXT >

[oR]

Role of the Linker and the OS Loader

When a program module is compiled, the compiler generates an object file that contains the machine language representation of the programming logic. However, the compiler cannot resolve any symbols that are external to the module. These symbols are still left as externals in the object file. For example, when the simulation program tv.cpp was compiled, the compiler did not have enough information to obtain the entry point for the procedure CVcr::GetSignalValue. So it just marked this method as EXTRN, indicating that the symbol representing the method needs to be resolved later.

 ; define all the external symbols  EXTRN  ?GetSignalValue@CVcr@@QAEJXZ:NEAR   ; CVcr::GetSignalValue  ; Other lines deleted for brevity  ; assembly language code for line vcr.GetSignalValue  call  ?GetSignalValue@CVcr@@QAEJXZ 

The original function GetSignalValue referenced in the source code has been represented by a different symbol within the compiled code. This is typical C++ compiler behavior. As the same function name can be defined multiple times either under different classes or with different argument types within the same class (referred to as function overloading), C++ compilers typically mangle the symbolic name of each entry point to uniquely identify a particular function. This technique is referred to as name mangling.

Once the object modules have been created, the linker combines all of the object modules and the libraries (a library is a collection of object modules) to create the final executable. It is the responsibility of the linker to resolve all the external symbols and replace them with appropriate procedure entry points. If any external symbol cannot be resolved, the linker will abort the process. In this case, either the final executable is never created or is partially created, depending on how the vendor of the linker chose to implement it.

In the case of the TV simulation program, had I not specified vcr.lib as an argument to the linker, the linker would have aborted the link process with the following error:

 tv.obj : error LNK2001: unresolved external symbol    "public: long __thiscall CVcr::GetSignalValue(void)"    (?GetSignalValue@CVcr@@QAEJXZ) 

When the executable (tv.exe) is run, the OS loader loads the executable image into memory and starts executing the code from the main entry point. The loader cannot load a partially created executable image.

Let s get back to the problem we are trying to solve. Our goal is to separate the programming implementation of the VCR from that of the TV so that we can field-replace just the VCR implementation in case of a defect. But we have a dilemma. The linker will not create the executable without resolving all the symbolic entry points. Even if it does, the loader will not load an incomplete image.

If only we could get away from linking the library statically. If only we could satisfy the linker by creating a fake entry point for each external sym-bol. If only the loader could resolve the external symbols before executing the image. If only we could

Is there a way to use a library at run time?

< BACK  NEXT >