Posted on : Sun , 07 2015 by : virusi
THEORY ON BUILD PROCESS :
The process of converting the source code representation of your embedded software into an executable binary image involves three distinct steps. First, each of the source files must be compiled or assembled into an object file. Second, all of the object files that result from the first step must be linked together to produce a single object file, called the relocatable program. Finally, physical memory addresses must be assigned to the relative offsets within the relocatable program in a process called relocation. The result of this third step is a file that contains an executable binary image that is ready to be run on the embedded system. Each of the steps of the embedded software build process is a transformation performed by software running on a general-purpose computer. The compiler, assembler, linker, and locator are all pieces of software that run on a host computer, rather than on the embedded system itself.
The job of a compiler is mainly to translate programs written in some human-readable language into an equivalent set of op codes for a particular processor. In that sense, an assembler is also a compiler but one that performs a much simpler one-to-one translation from one line of human-readable mnemonics to the equivalent op(operation code) code. Each processor has its own unique machine language, so you need to choose a compiler that is capable of producing programs for your specific target processor. Compiler almost always runs on the host computer. The contents of an object file can be thought of as a very large, flexible data structure. The structure of the file is usually defined by a standard format like the Common Object File Format (COFF) or Extended Linker Format (ELF). Although many compilers (particularly those that run on Unix platforms) support standard object file formats like COFF and ELF (gcc supports both), there are also some others that produce object files only in proprietary formats. Most object files begin with a header that describes the sections that follow. Each of these sections contains one or more blocks of code or data that originated within the original source file. However, these blocks have been regrouped by the compiler into related sections. For example, all of the code blocks are collected into a section called text, initialized global variables (and their initial values) into a section called data, and uninitialized global variables into a section called bss.
All of the object files resulting from step one must be combined in a special way before the program can be executed. The object files themselves are individually incomplete, most notably in that some of the internal variable and function references have not yet been resolved. The job of the linker is to combine these object files and, in the process, to resolve all of the unresolved symbols. The output of the linker is a new object file that contains all of the code and data from the input object files and is in the same object file format. It does this by merging the text, data, and bss sections of the input files. So, when the linker is finished executing, all of the machine language code from all of the input object files will be in the text section of the new file, and all of the initialized and uninitialized variables will reside in the new data and bss sections, respectively. While the linker is in the process of merging the section contents, it is also on the lookout for unresolved symbols. For example, if one object file contains an unresolved reference to a variable named foo and a variable with that same name is declared in one of the other object files, the linker will match them up. The unresolved reference will be replaced with a reference to the actual variable. In other words, if foo is located at offset 14 of the output data section, its entry in the symbol table will now contain that address. If the same symbol is declared in more than one object file, the linker is unable to proceed. It will likely appeal to the programmer-by displaying an error message-and exit. However, if a symbol reference instead remains unresolved after all of the object files have been merged, the linker will try to resolve the reference on its own. The reference might be to a function that is part of the standard library, so the linker will open each of the libraries described to it on the command line (in the order provided) and examine their symbol tables. If it finds a function with that name, the reference will be resolved by including the associated code and data sections within the output object file. After merging all of the code and data sections and resolving all of the symbol references, the linker produces a special “relocatable” copy of the program. In other words, the program is complete except for one thing: no memory addresses have yet been assigned to the code and data sections within.
Locating :The tool that performs the conversion from relocatable program to executable binary image is called a locator. By providing information about the memory on the target board as input to the locator. The locator will use this information to assign physical memory addresses to each of the code and data sections within the reloadable program. It will then produce an output file that contains a binary memory image that can be loaded into the target ROM. In many cases, the locator is a separate development tool however this functionality is built right into the linker. Whether you are writing software for a general-purpose computer or an embedded system, at some point the sections of your relocatable program must have actual addresses assigned to them. In the first case, the operating system does it for you at load time. The result of this final step of the build process is an absolutely located binary image that can be downloaded to the embedded system or programmed into a read-only memory device.