There are a variety of C compilers available for many different platforms. Some compilers must be purchased and some are free to use. We will be using GNU gcc in our examples mainly due to its availability on many different platforms.
While using this site, you agree to have read and accepted our Terms of Service and Privacy Policy. Home C Language. Please re-enable javascript in your browser settings. Each of these files contains a translation of your source code file into a machine language file -- but you can't run them yet! You need to turn them into executables your operating system can use. That's where the linker comes in. Linking Linking refers to the creation of a single executable file from multiple object files.
In this step, it is common that the linker will complain about undefined functions commonly, main itself. During compilation, if the compiler could not find the definition for a particular function, it would just assume that the function was defined in another file. If this isn't the case, there's no way the compiler would know -- it doesn't look at the contents of more than one file at a time.
The linker, on the other hand, may look at multiple files and try to find references for the functions that weren't mentioned. You might ask why there are separate compilation and linking steps. First, it's probably easier to implement things that way. The compiler does its thing, and the linker does its thing -- by keeping the functions separate, the complexity of the program is reduced.
It is a command-line tool that takes the names of all the object files, and possibly libraries, to be linked as arguments. With embedded software, a special object file that contains the compiled startup code, which is covered later in this section, must also be included within this list. The GNU linker also has a scripting language that can be used to exercise tighter control over the object file that is output.
If the same symbol is declared in more than one object file, the linker is unable to proceed. It will likely complain to the programmer by displaying an error message and exit. On the other hand, if a symbol reference 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, such as memcpy , strlen , or malloc , that is part of the standard C 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 the linker thus discovers a function or variable with that name, the reference will be resolved by including the associated code and data sections within the output object file.
Unfortunately, the standard library routines often require some changes before they can be used in an embedded program.
One problem is that the standard libraries provided with most software development tool suites arrive only in object form.
You only rarely have access to the library source code to make the necessary changes yourself. Thankfully, a company called Cygnus which is now part of Red Hat created a freeware version of the standard C library for use in embedded systems. This package is called newlib.
The library can then be linked with your embedded software to resolve any previously unresolved standard library calls. 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. The addresses of the symbols in the linking process are relative. In fact, if there is an operating system, the code and data of which it consists are most likely within the relocatable program too.
The entire embedded application—including the operating system—is frequently statically linked together and executed as a single binary image.
One of the things that traditional software development tools do automatically is insert startup code : a small block of assembly language code that prepares the way for the execution of software written in a high-level language.
Each high-level language has its own set of expectations about the runtime environment. For example, programs written in C use a stack. Space for the stack has to be allocated before software written in C can be properly executed.
That is just one of the responsibilities assigned to startup code for C programs. Most cross-compilers for embedded systems include an assembly language file called startup. The location and contents of this file are usually described in the documentation supplied with the compiler.
Startup code for C programs usually consists of the following series of actions:. Typically, the startup code will also include a few instructions after the call to main. These instructions will be executed only in the event that the high-level language program exits i.
Depending on the nature of the embedded system, you might want to use these instructions to halt the processor, reset the entire system, or transfer control to a debugging tool.
Because the startup code is often not inserted automatically, the programmer must usually assemble it himself and include the resulting object file among the list of input files to the linker. He might even need to give the linker a special command-line option to prevent it from inserting the usual startup code.
Working startup code for a variety of target processors can be found in a GNU package called libgloss. In some cases, a debug monitor or ROM monitor is the first code executed when the board powers up. In the case of the Arcom board, there is a debug monitor called RedBoot. This software on the Arcom board contains the startup code and performs the tasks listed previously to initialize the hardware to a known state.
Because of this, programs downloaded to run in RAM via RedBoot do not need to be linked with startup code and should be linked but not located. After the hardware has been initialized, RedBoot sends out a prompt to a serial port and waits for input from the user you to tell it what to do. RedBoot supports commands to load software, dump memory, and perform various other tasks.
We will take a look at using RedBoot to load a software program in the next chapter. The tool that performs the conversion from relocatable program to executable binary image is called a locator. It takes responsibility for the easiest step of the build process. In fact, you have to do most of the work in this step yourself, by providing information about the memory on the target board as input to the locator. The locator uses this information to assign physical memory addresses to each of the code and data sections within the relocatable program.
It then produces an output file that contains a binary memory image that can be loaded into the target. Whether you are writing software for a general-purpose computer or an embedded system, at some point the sections of your relocatable program must be assigned actual addresses. Sometimes software that is already in the target does this for you, as RedBoot does on the Arcom board. In some cases, there is a separate development tool, called a locator , to assign addresses.
However, in the case of the GNU tools, this feature is built into the linker ld. The memory information required by the GNU linker can be passed to it in the form of a linker script.
Such scripts are sometimes used to control the exact order of the code and data sections within the relocatable program. But here, we want to do more than just control the order; we also want to establish the physical location of each section in memory.
What follows is an example of a linker script for the Arcom board. The first executable instruction is designated with the ENTRY command, which appears on the first line of the preceding example. In this case, the entry point is the function main. Names in the linker command file that begin with an underscore e. The linker will use these symbols to resolve references in the input object files.
So, for example, there might be a part of the embedded software usually within the startup code that copies the initial values of the initialized variables from ROM to the data section in RAM.
A linker script can also use various commands to direct the linker to perform other operations. The output of this final step of the build process is a binary image containing physical addresses for the specific embedded system. This executable binary image can be downloaded to the embedded system or programmed into a memory chip. If another hardware platform is used, a similar process should be followed using the tools and conventions that accompany that hardware.
The installation procedure for the software development tools is provided in Appendix B. Once the tools are installed, the commands covered in the following sections are entered into a command shell. For Windows users, the command shell is a Cygwin bash shell Cygwin is a Unix environment for Windows ; for Linux users, it is a regular command shell. In this and subsequent chapters, commands entered in a shell environment are indicated by the number sign prompt.
We will next take a look at the individual commands in order to manually perform the three separate tasks compiling, linking, and locating described earlier in this chapter. Then we will learn how to automate the build procedure with makefiles.
As we have implemented it, the Blinking LED example consists of two source modules: led. The first step in the build process is to compile these two files. The basic structure for the gcc compiler command is:. Here are the actual commands for compiling the C source files:. We broke up the compilation step into two separate commands, but you can compile the two files with one command. To use a single command, just put both of the source files after the options.
If you wanted different options for one of the source files, you would need to compile it separately as just shown. Running these commands will be a good way to verify that the tools were set up properly.
The result of each of these commands is the creation of an object file that has the same prefix as the. So if all goes well, there will now be two additional files— led. The compilation procedure is shown in Figure We now have the two object files— led. As we discussed earlier, the GNU linker performs the linking and locating of the object files.
For the third step, locating, there is a linker script file named viperlite. The basic structure for the linker and locater ld command is:. To set the output filename if this option is not included, ld will use the default output filename a. The order of the object files determines their placement in memory.
Because we are not linking in any startup code, the order of the object files is irrelevant. If startup code were included, you would want that object file to be located at the proper address. The linker script file can be used to specify where you want the startup routine and other code to reside in memory. Furthermore, you can also use the linker script file to specify exact addresses for code or data, should you find it necessary to do so.
0コメント