How Does Compiling Work?

[mikets]

In the Windows platform, when you are calling functions that reside in another DLL, you link to a .lib file. This .lib file contains stub functions that call into an indirect function table. This function table will be resolved (dynamic linked) to the real functions when your program is loaded into memory. This allows multiple programs to link to the same copy of the DLL in memory thus saving memory.

[EdenA]

Originally Posted by mikets

In the Windows platform, when you are calling functions that reside in another DLL, you link to a .lib file. This .lib file contains stub functions that call into an indirect function table. This function table will be resolved (dynamic linked) to the real functions when your program is loaded into memory. This allows multiple programs to link to the same copy of the DLL in memory thus saving memory.

Actually, I believe that the exe (Portable Executable) file contains a table of import entries at a fixed location in virtual memory in the header of the PE where the program calls to for functions in DLLs to be imported. The Windows program loader at runtime then iterates through the import table entires, patching the code at the entries to JMP to the DLL's imported functions in virtual memory (where they are located at a given time). I believe the .lib file's contents will change whether the library is shared or static.

If the library is static, it's code will be stuck in with the rest of the application's which is using it, and the .lib file will probably contain the object file code (an intermediate form of code before machine code, with stuff such as relocation information) of the library.

If the library is shared, the .lib file will probably contain a list of functions which exist in the shared library. The actual code will be separated from the application's which uses it- in a PE file on Windows (.exe, .dll) or .out in vxWorks. This makes it possible to update the library an application is using without recompiling the application, also promoting modularity and code reuse. The purpose of the .lib file for applications on conventional operating systems here is usually to facilitate the process of "static" linking.

However, a lot of this information is irrelevant to the poster's question.

For programming with the vxWorks operating system on the cRIO, it is important to understand in the compile process the distinction between "static" and "dynamic" linking. On vxWorks, .out files (your program) are linked dynamically. What does this mean?

Lets say you have a C/C++ program with a function declared in a header file, and your code calls it, but you haven't compiled the definition of the function (it is unwritten in your project). On a conventional operating system such as Windows or Unix the compiler will resolve links between functions and function calls at compile time- meaning that the application's exe will know for sure where those functions are once it is constructed.

In other words, if you are using a function which is declared to exist but not defined you will get an error at compile time. This is static linking.

On vxWorks, you will not get an error at compile time. You will get an error at runtime, because when vxWorks loads programs it dynamically links all applications calls to functions at runtime (resolves where functions are at the load time, instead of compile time). This is dynamic linking.

Discovering linker errors at runtime can lead to some hard-to-resolve crashes if you aren't debugging an application when it's run by the vxWorks program loader. So, you should usually always run your program via debug kernel task.

The WPI library is not part of the cRIO image. It is a static library, merged in with the rest of your code at compile time. That's why it is so easy to recompile and use your own version of WPI lib.

For a complete view of the traditional compilation process, I would recommend reading Compilers: Principles, Techniques, and Tools (the dragon book).

[masoug]

Okay, I see how this works now...
Thanks!

[jhersh]

The thing that makes the VxWorks (and Linux as well) different from what you see on Windows is that even though WPILib is statically linked with your application, the loader has the chance to resolve any missing symbols at runtime. Because of this, even if the linker knows that it can't find all the WPILib symbols when it's linking (because it's the wrong version of the FPGA for instance) it doesn't know that those symbols won't exist when actually loading it, so you get no error.

On Windows, all symbols you want to link against must exist when the application is linked. That's why on Windows you have a stub library to provide those symbols. This allows the link to know if the symbols you expect to have are there and you will get an error when building your program if they aren't. There are no stub libraries on VxWorks. There's always the case where the stub library and the DLL are inconsistent, and you'll get runtime loader errors in that case on Windows.