[An Introduction to GCC 学习笔记] 15 How the compiler works, Identifying files

The Preprocessor

• The first stage of the compilation process is the use of the preprocessor to expand macros and included header files.
• To perform this stage, GCC executes the following command:

$ cpp hello.c > hello.i

• The result is a file ‘hello.i’ which contains the source code with all macros expanded. By convention, preprocessed files are given the file extension ‘.i’ for C programs and ‘.ii’ for C++ programs. In practice, the preprocessed file is not saved to disk unless the ‘-save-temps’ option is used.

The Compiler

• The next stage of the compilation process is the actual compilation of preoprocessed source code to assembly language, for a specific processor.
• The command line option ‘-S’ instructs gcc to convent the preprocessed C source code to assembly language without creating an object file:

$ gcc -Wall -S hello.i

The Assembler

• The purpose of the assembler is to convert assembly language into machine code and generate an object file.
• When there are calls to external functions in the assembly source file, the assembler leaves the addresses of the external functions undefined, to be filled in later by the linker.
• The assembler can be invoked with the following command line:

$ as hello.s -o hello.o

The Linker

• The final stage of compliation is the linking of object files to create an executable. In practice, an executable requires many external functions from system and C run-time(crt) libraries.
• The actual link commands used internally by GCC are complicated. Fortunately the entire linking process is handled transparently by gcc when invoked as follows:

$ gcc hello.o

• The above command links the object file ‘hello.o’ to the C standard library, and produces an executable file ‘a.out’.
• An object file for a C++ program can be linked to the C++ standard library in the same way with a single g++ command.

Identifying Files

When a source file has been compiled to an object file or executable the options used to compile it are no longer obvious. The file command looks at the contents of an object file or exeutable and determines some of its characteristics.

• ELF~The internal format of the executable file(ELF stands for “Executable and Linking Format”, other formats such as COFF “Common Object File Format” are used on some older operating system(e.g. MS-DOS)).
• LSB~Compiled for a platform with least significant byte first word-ordering, such as Intel and AMD x86 processors(The alternative MSB most significant byte first is used by other processors, such as the Motorola 680x0).
• not stripped~The executable contains a symbol table, which can be removed with the strip command.

Examining the Symbol Table

Executables and object files can contain a symbol table for debugging. This table stores the location of functions and variables by name, and can be displayed with the nm command.

• Most of the symbols are for internal use by the compiler and operating system. A ‘T’ in the second column indicates a function that is defined in the object file. while a ‘U’ indicates a function which is undefined(and should be resolved by linking against another object file).
• The most common use of the nm command is to check whether a library contains the definition of a specific function, by lokking for a ‘T’ entry in the second column against the function name.
• You can get a complete explanation of the output of nm in the GNU Binutils manual.

Finding Dynamically Linked Libraries

• When a program has been compiled using shared libraries it needs to load those libraries dynamically at run-time in order to call external functions.
• The command ldd examines an executable and displays a list of the shared libraries that it needs. These libraries are referred to as the shared library dependencies of the executable.

$ gcc -Wall hello.c
$ ldd a.out

• The ldd command can also be used to examine shared libraries themselves, in order to follow a chain of shared library dependencies.