Compiler and Development Tools

These are the main tools for developing projects with GNUPro Toolkit.

cpp	C preprocessor (see cpp, the GNU Preprocessor; see also The C Preprocessor in GNUPro Compiler Tools)
diff diff3 sdiff	Comparison tools for text files (see Using diff & patch in GNUPro Development Tools)
gcc	ISO-conforming compiler collection (see gcc and g++, the GNU Compilers; see also Using GNU CC in GNUPro Compiler Tools)
gcov	Coverage analyzer, for testing code for efficiency and performance, and for use as a profiling tool (see Using GNU CC in GNUPro Compiler Tools)
gdb -nw	Debugger for debugging with command line input (see gdb, the Debugging Tool; see also Debugging with GDB in GNUPro Debugging Tools)
gdb	Debugger with a graphical user interface; it is known as Insight and is also conceptually known as gdbtk (see Insight, a GUI Debugger and Debug with Insight; see also Insight, the GNUPro Debugger GUI Interface in GNUPro Debugger Tools)
ld	Linker (see ld, the GNU Linker; see also Using ld in GNUPro Development Tools)
make	Compilation control program (see make, the GNU Recompiling Tool; see also Using make in GNUPro Utilities)
patch	Installation tool for source fixes (see Using diff & patch in GNUPro Development Tools)

Libraries

See newlib and libstdc++, the GNU Libraries; see also GNUPro Libraries for documentation regarding the following libraries.

libc	ANSI C runtime library ( only available for cross-development)
libio	C++ iostreams library
libm	C math subroutine library ( only available for cross-development)
libstdc++	C++ class library

Auxiliary Development Tools

GNUPro Toolkit also provides the following components for general development.

as	Assembler (see as, the GNU Assembler; see also Using as in GNUPro Auxiliary Development Tools)
cygwin	Win32 porting layer for UNIX applications (see Using Cygwin to Port UNIX Applications to Windows, Using Cygwin, and see http://sources.redhat.com/cygwin/)
info	Online documentation tools (see Using info, the Documentation Tools and Using info in GNUPro Auxiliary Development Tools)
man	man pages, the standard UNIX online documentation
redboot	A ROM monitor for embedded target application use (see RedBoot for Remote Debugging)

The GNU binary utilities provide functionality beyond the main development tools (see Using binutils in GNUPro Auxiliary Development Tools).

addr2line	Converts addresses into file names and line numbers
ar	Creates, modifies and extracts from object code archives
c++filt	Demangles and deciphers encoded C++ symbol names
dlltool	Creates files for builds, using dynamic link libraries (DLLs)
nm	Lists symbols from object files
nlmconv	Converts object code into a Netware Loadable Module (NLM)
objcopy	Copies and translates object files
objdump	Displays information from object files
ranlib	Generates index to archive contents
readelf	Displays information about ELF format object files
size	Lists file section sizes and total sizes
strings	Lists printable strings from files
strip	Discards symbols
windres	Manipulates Win32 resources; to use GNU tools on Windows systems, see http://sources.redhat.com/cygwin/

gcc and g++, the GNU Compilers

The GNU Compiler Collection (GCC), is a complete set of tools for compiling programs written in C, C++, Objective C, or languages for which you have installed front-ends. The GNU compiler uses the following utilities:

• cpp
  GNU preprocessor that processes all the header files and macros that your target requires (see cpp, the GNU Preprocessor).
• as
  GNU assembler that produces binary code from assembly language code and puts it in an object file (see as, the GNU Assembler).
• ld
  GNU linker that binds the code to addresses, links the startup file and libraries to an object file, and then produces an executable binary image (see ld, the GNU Linker).

To invoke the compiler, type:

gcc option, option...

Providing options allows you to stop the compile process at intermediate stages. Use commas to separate the options.

There are many options available for providing a specific type of compiled output, others for preprocessing, and others controlling assembly, linking, optimization, debugging, and other target-specific functions. For instance, call the driver with a -v option to see precisely which options are in use for each compilation pass.

There are four implicit file extensions: .c (for C source code which must be preprocessed), .C (for C++ source code which must be preprocessed), .s (for assembler code), and .S (for assembler code that must be preprocessed).

When referring to C++ compilation, g++ is its customary name. Because there is only one compiler, it is also accurate to use the gcc call, no matter what the language context. The g++ distinction is more useful when the emphasis is on compiling C++ programs, with the GNU compiler acting not merely as a preprocessor, but building object code directly from your C++ program source.

There is no intermediate C version of the program; avoiding an intermediate C representation of the program means that you get better object code and better debugging information. The GNU debugger works with this information in the object code to give you comprehensive C++ source-level editing capabilities.

When you compile C or C++ programs, the compiler inserts a call at the beginning of main to a _ _main support subroutine. To avoid linking to the standard libraries, specify the -nostdlib option. (Including -lgcc at the end of your compiler command line resolves this reference and links only with the compiler support library libgcc.a ; ending your command's input with it ensures that you get a chance to link first with any of your own special libraries).

_ _main is the initialization routine for C++ constructors. Because GNU C is meant to interoperate with GNU C++, even C programs must have this call; otherwise, C++ object files linked with a C main might fail.

Compilation can involve up to four stages, always in the following order:

• preprocessing
• compiling
• assembling
• linking

The first three stages apply to an individual source file: preprocessing establishes the type of source code to process, compiling produces an object file, assembling establishes the syntax that the compiler expects for symbols, constants, expressions and the general directives. The last stage, linking, completes the compilation process, combining all object files (newly compiled, and those specified as input) into an executable file.

For more information on the GNU compiler and its options, see Using GNU CC in GNUPro Compiler Tools.

cpp, the GNU Preprocessor

cpp is a C-compatible macro preprocessor that works with the GNU compiler to direct the parsing of C preprocessor directives. Preprocessing directives are the lines in your program that start with a # directive name (a # sign followed by an identifier). For instance, cpp merges #include files, expands macro definitions, and processes #ifdef sections. Another example is #define , a directive that defines a macro ( #define must be followed by a macro name and the macro's intended expansion).

To see the output of cpp, invoke gcc with the -E option; the preprocessed file will print on stdout .

The C preprocessor provides the following separate facilities.

• Inclusion of header files
  Declarations that can be substituted into your program.
• Macro expansion
  When defining macros, which are abbreviations for arbitrary fragments of C code, the C preprocessor replaces them with their definitions throughout a program.
• Conditional compilation
  Using special preprocessing directives, include or exclude parts of a program according to various conditions.
• Line control
  Using a program to combine or rearrange source files into an intermediate file that is then compiled, use line control to provide a source line's origin.

There are two convenient options to assemble files that require C-style preprocessing. Both options depend on using the compiler driver program, gcc, instead of directly calling the assembler.

• Name the source file using the extension .S (capitalized), rather than .s (the .S indicates an assembly language program that requires C-style preprocessing).
• Specify a source language explicitly for a situation, using the -xassembler-with-cpp option.

For more information on cpp, see The C Preprocessor in GNUPro Compiler Tools.

ld, the GNU Linker

The GNU linker, ld , does the following:

• Resolves the code addresses, object, and archive files
• Relocates the archive files' data
• Links the startup code and additional libraries to the binary code
• Combines symbol references
• Usually, as the last step in compiling a program, produces an executable binary image. This means producing a linker script to control every link; such a script derives from the linker command language.

The main purpose of a linker script is to describe how sections in the input files should map into the output file and to control memory layout of the output file. When necessary, the linker script also directs the linker to perform other operations. For an example of a linker script, see The Linker Script.

The linker combines an output file and each input file in a special data format known as an object file format, with each file being an object file. The output file is often called an executable, but for simplicity, refer to it as an object file.

Each object file has, among other things, a list of sections. Sections are blocks of bytes of your program. The linker reads many object files (partial programs) and combines their contents to form a program that will run. When the GNU assembler, as, emits an object file, the partial program is assumed to start at address 0. Then ld assigns the final addresses for the partial program so that different partial programs do not overlap. This is actually an oversimplification of relocation, but it suffices to explain how as uses sections.

ld moves sections to their run-time addresses. These sections slide to their run-time addresses as rigid units; their length does not change and neither does the order of bytes within them. Assigning run-time addresses to sections is called relocation. It includes the task of adjusting mentions of object-file addresses so they refer to the proper run-time addresses. For the H8/300 and H8/500, and for the Hitachi SH, for instance, the assembler (as) pads sections as needed to ensure they end on a word (16 bit) boundary. A section is in an input file as an input section; similarly, a section in an output file is an output section. Each section in an object file has a name and a size. Most sections also have an associated block of data, known as the section contents. A section may be marked as loadable, meaning to load the contents into memory when running the output file. A section with no contents may be allocatable, meaning to set aside an area in memory, but without loading anything there (in some cases this memory must be zeroed out). A section that is neither loadable nor allocatable typically contains some sort of debugging information.

Every loadable or allocatable output section has two addresses. The first is the virtual memory address (VMA), the address the section will have when the running the output file. The second is the load memory address (LMA), the address at which the section will load. In most cases the two addresses will be the same. An example of when they might be different is when a data section is loaded into ROM, and then copied into RAM when the program starts (this technique is often used to initialize global variables in a ROM-based system). In that case, the ROM address would be the LMA, and the RAM address would be the VMA. To see the sections in an object file, use the objdump binary utility with the -h option.

Every object file also has a list of symbols , known as the symbol table. A symbol may be defined or undefined. Each symbol has a name, and each defined symbol has an address, among other information. If you compile a C or C++ program into an object file, you will get a defined symbol for every defined function and global or static variable. Every undefined function or global variable that is referenced in the input file will become an undefined symbol. You can see the symbols in an object file by using the nm binary utility, or by using the objdump binary utility with the -t option.

The linker will use a default script that compiles into the linker executable, if you do not supply one. Use the --verbose option to display the default linker script. Certain options (such as -r or -N) will affect the default linker script. Supply your own linker script with the -T option. Use linker scripts implicitly by naming them as input files to the linker, as though they were files to be linked.

ld accepts linker command language files, written in a superset of AT&T's Link Editor Command Language syntax, to provide explicit and total control over the linking process. ld uses the general purpose BFD libraries to operate on object files (libraries whose name derives from binary file descriptors); ld can then read, combine, and write object files in many different formats, such as COFF or a.out formats. You can link different formats to produce any available kind of object file. In addition to its flexibility, the GNU linker also provides more diagnostic information than other linkers. For example, many linkers stop executing upon encountering an error, whereas ld continues executing, whenever possible, allowing you to identify other errors (or, in some cases, to get an output file in despite the error).

For more information, see Using ld in GNUPro Development Tools.

make, the GNU Recompiling Tool

The GNU make utility automatically determines which pieces of a large program you need to recompile, then issues commands to recompile them. Originally implemented by Richard Stallman and Roland McGrath, make conforms to IEEE Standard 1003.2-1992 (POSIX.2). make is compatible with any programming language whose compiler can run with command line input from a shell. make is not limited only to programs; it is also for any task where some files must update automatically whenever other files associated with them change.

To use make, you must write a file (a makefile) that describes the relationships among files in your program and provides commands for updating each file. In a typical program, the executable file is updated from object files, which are in turn made by compiling source files. When using make to recompile an executable, the result may change source files in a directory; if you changed a header file, to be safe, you must recompile each source file that includes that header file. Each compilation produces an object file corresponding to the source file. If any source file has been recompiled, all the object files, whether newly made or saved from previous compilations, must be linked together to produce the new executable.

The make program uses the makefile database and the last modified files to decide which of the other files needs updating. For each of those files, make implements the commands recorded in the database of the makefile. The makefile has rules that explain how and when to remake certain files that are the targets of a particular rule. A simple makefile has the following form for rules:

target ... : dependency ...
command

target is usually the name of a file that a program generates; examples of targets are executable or object files. A target can also be the name of an action to carry out, such as with the clean command (a command that, to simplify, deletes all files from a build directory before building). dependency is a file that is used as input to create the target. A target often depends on several files. command is for make to activate. A rule may have more than one command, with each command on its own line.

IMPORTANT!

Every command line must start with a tab character in order to distinguish command lines from other lines in the makefile.

Usually a command is in a rule with dependencies and serves to create a target file if any dependencies change. However, the rule that specifies commands for the target does not require dependencies. For instance, the rule containing the delete command that associates with the target, clean, does not have dependencies. Define clean as a pseudo-target with the ".PHONY: clean" command to avoid dependency problems.

make activates commands on the dependencies to create or to update the target. A rule can also explain how and when to activate a command. A makefile may contain other text besides rules; a simple makefile requires only rules. Rules generally follow the same pattern.

Makefile shows a simplified makefile that describes the way an edit executable file depends on eight object files which, in turn, depend on eight C source and three header files. In Makefile, all of the C files include defs.h , but only those defining editing commands include command.h , and only low level files that change the editor buffer include buffer.h files.

Makefile

edit : main.o kbd.o command.o display.o insert.o search.o files.o utils.o cc -o edit main.o kbd.o command.o display.o insert.o search.o files.o utils.o main.o : main.c defs.h cc -c main.c kbd.o : kbd.c defs.h command.h cc -c kbd.c command.o : command.c defs.h command.h cc -c command.c display.o : display.c defs.h buffer.h cc -c display.c insert.o : insert.c defs.h buffer.h cc -c insert.c search.o : search.c defs.h buffer.h cc -c search.c files.o : files.c defs.h buffer.h command.h cc -c files.c utils.o : utils.c defs.h cc -c utils.c clean : rm edit main.o kbd.o command.o display.o insert.o search.o \ files.o utils.o

The example makefile's targets include the executable file, edit, and the main.o and kbd.o object files. main.c and defs.h are the dependency files. Each .o file is both a target and a dependency. When a target is a file, it needs to be recompiled or relinked if any of its dependencies change. Update any dependencies that automatically generate first. In Makefile, edit depends on eight object files; the object file, main.o, depends on the source file, main.c, and on the defs.h header file. A shell command follows each line that contains a target and dependencies, saying how to update the target file; a tab character must come at the beginning of every command line to distinguish command lines from other lines in the makefile. make does not know anything about how the commands work; it is up to you to supply commands that will update the target file properly. All make does is execute the commands in the rule you have specified when the target file needs updating.

For more details, see Using make in GNUPro Development Tools.

gdb, the Debugging Tool

The GNU debugger, gdb, enables you to see what is happening inside a program as it executes and what it was doing if it crashes. Using gdb, you can :

• Start a program, or debug one that is already running
• Stop the program
• See where the program was when you stopped it
• Examine the program's stack, variables, and data structures
• Continue running the program.

To give gdb the information it needs to perform these tasks, you should pass the "-g " flag to gcc when you compile and link your programs. For example, you could compile the source file foo.c with the command:

$ gcc -g foo.c -o foo

Then, you can run that program under the debugger like this:

$ gdb -nw foo

GNU gdb gnupro-02r1

...

(gdb)

The "-nw" option causes gdb to use its command-line interface for debugging; "(gdb)" is gdb's command prompt.

note

gdb also has a graphical user interface called Insight; see Insight, a GUI Debugger and Insight, the GNUPro Debugger GUI Interface in GNUPro Debugging Tools.

At the (gdb) prompt you can use the following commands:

• break function_name

Set a breakpoint at function_name; gdb will stop your program each time it calls function_name.

• break file_name : line_number

Set a breakpoint at line line_number of the source file file_name; gdb will stop your program each time it reaches that line.

• run args

Start the program running, passing it args as its command-line arguments.

• attach process_id

Stop the program whose numeric process id is process_id.

• backtrace

Show the series of function calls that led to the function your program is currently executing, and the arguments passed in each call.

• print expression

Evaluate an arbitrary C or C++ expression, and print its value. You can use this to see the values of global and local variables, function arguments, data structures.

You can use the frame command, described below, to select the function call whose local variables the print command should use.

• frame n

Select the n th function call from the top of the stack. frame 0 selects the top of the stack.

• continue

Let your program resume its execution.

• step

Let your program resume its execution, but only until it leaves the source line it is currently stopped on. Use this command repeatedly to run your program one line at a time.

• next

Like step, but if the current line includes any function calls, do not stop upon entering the function; continue the program until it returns.

• exit

Exit gdb.

• help command

Print a short description of the gdb command command.

If you want to interrupt your program while it is running, type Ctrl-C. This suspends the program execution, tells you where it stopped, and gives you a (gdb) prompt.

gdb Example

Here is an example of using gdb. First, this is the source file, hello.c:

$ cat hello.c

#include <stdlib.h>

#include <stdio.h>

int

main (int argc, char **argv)

{

printf ("Hello, world.\n");

exit (0);

}

$

1. Compile this program with gcc; the "-g" flag tells gcc to include extra information in the executable file that gdb needs to debug the program:

$ gcc hello.c -g -o hello

2. Start the debugger:

$ gdb -nw hello

GNU gdb gnupro-02r1

Copyright 2001 Free Software Foundation, Inc.

GDB is free software, ...

(gdb)

3. Set gdb to stop the program when it reaches the function main:

(gdb) break main

Breakpoint 1 at 0x10648: file hello.c, line 7.

(gdb)

4. Start the program running; it hits the breakpoint in main and stops.

(gdb) run

Starting program: /thud/home/jimb/play/hello

Breakpoint 1, main (argc=1, argv=0xefffdc34) at hello.c:7

7 printf ("Hello, world.\n");

(gdb)

5. Use the print command to examine the program's variables and data structures:

(gdb) print argc

$1 = 1

(gdb) print argv[0]

$2 = 0xefffdf08 "/thud/home/jimb/play/hello"

(gdb) print argv[1]

$3 = 0x0

(gdb)

6. You can run the program one statement at a time, using step and next. Step over the call to printf completely by giving the next command. The call to printf produces its output and gdb stops the program at the next statement in main:

(gdb) next

Hello, world.

9 exit (0);

(gdb)

7. You can use the backtrace command to see the currently active function calls. In this example, there is only one:

(gdb) backtrace

#0 main (argc=1, argv=0xefffdc34) at hello.c:9

(gdb)

8. Now use continue to let the program resume execution. It runs to completion:

(gdb) continue

Continuing.

Program exited normally.

(gdb)

You can use gdb to debug programs running on an embedded board; see Using RedBoot for Remote Debugging.

For more information on the GNU debugger, see Debugging with GDB in GNUPro Debugging Tools.

Insight, a GUI Debugger

Besides the standard command line based debugger, gdb, GNUPro Toolkit includes Insight, a debugger with a graphical user interface. Insight works on a range of host systems and target microprocessors. It allows complete access to the program state for source and assembly levels, and provides the ability to manage breakpoints, variables, registers, memory, and threads.

By adding a series of intuitive views into the debugging process, Insight provides you with a wide range of system information. See A Composite View of Working with Insight for an example of the windows that Insight provides for analyzing and debugging programs.