| Red Hat Docs > Manuals > GNUPro Toolkit Manuals > |
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNUPro Toolkit's C and C++ compilers, macro-assembler, debugger, binary utilities, libraries, and other development tools provide productivity, flexibility, performance, and portability. This chapter begins with a summary of the tools, then describes each tool in more detail.
To use a tool, open your system's terminal shell window and enter the
tool's name as a command (gcc, for instance, invokes the
compiler, and insight invokes Insight). For a summary of the
GNUPro Toolkit, see Compiler and Development Tools,
Libraries, and Auxiliary Development Tools.
To learn about working with the tools, see Developing with GNUPro Toolkit, and Rebuilding the Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following tools are the main tools for developing projects with GNUPro Toolkit.
cpp
cpp, the GNU
Preprocessor}}; see also The C Preprocessor in GNUPro
Compiler Tools)
diff
diff3
sdiff
diff &
patch in GNUPro Development Tools)
gcc
gcc, the GNU Compiler
Collection}}; also Using GCC in GNUPro Compiler Tools)
g++
gcov
gdb
gdb}; also Debugging with
GDB in GNUPro Debugger Tools)
insight
gdbtk (see section a GUI Debugger}, and Debugging with Insight);
see also Insight, the GNUPro Debugger GUI Interface in
GNUPro Debugging Tools) </CELL>
ld
ld, the GNU Linker}}; see also
Using ld in GNUPro Development Tools)
make
make}; see also Using
make in GNUPro Utilities)
patch
diff
& patch in GNUPro Development Tools)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
@xref{newlib & libstdc++ the C & C++ Libraries,, {newlib & libstdc++, the C & C++ Libraries}}; see also GNUPro Libraries for documentation regarding the following libraries.
libc
libm
libstdc++
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNUPro Toolkit also provides the following components for general development.
as
as, the GNU
Assembler}}; also Using as in GNUPro Auxiliary
Development Tools)
cygwin
info
info}, and Using
info in GNUPro Auxiliary Development Tools)
man
man pages, the standard UNIX online documentation
The GNU binary
utilities provide functionality beyond the main development tools
(@xref{binutils the GNU Binary Utilities,, {binutils, the GNU
Binary Utilities}}; see also Using binutils in
GNUPro Auxiliary Development Tools).
addr2line
ar
c++filt
dlltool
nm
objcopy
objdump
ranlib
readelf
size
strings
strip
windres
http://sources.redhat.com/cygwin/
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
gcc, the GNU Compiler Collection The GNU Compiler Collection (also known as GCC), is a complete set of tools for compiling programs written in C, C++, or languages for which you have installed front-ends, invoking the GNU compiler passes with the following utilities:
cpp
cpp,
the GNU Preprocessor}})
as
as,
the GNU Assembler}})
ld
ld, the GNU Linker}})
To invoke the compiler, type:
gcc options |
options signifies input that allows you to control how the program compiles, i.e. interrupt a compile process at intermediate stages. Use commas to separate options. There are many options available that provide specific types of compiled output, some for preprocessing, others controlling assembly, linking, optimization, debugging, and still others for target-specific functions. For instance, call the compiler with a `-v' option to see precisely which options are in use for each compilation pass.
gcc implicitly recognizes the following file extensions:
.c (for C source code which must be preprocessed), .C (for
C++ code), .s (for assembler code), and .S (for assembler
code which must be preprocessed).
Compilation involves up to four stages, always in the following order:
The first three stages apply to individual source files. Preprocessing interprets special directives in the source file, performing text-based substitutions. Compiling converts the preprocessed high level language source code into assembler source code. Assembling then converts this into binary machine code and places it into an object file. Finally, the last stage, linking, combines multiple object files (either standalone or in library archives) into a single executable file.
For more information on working with the GNU compiler and using its options, see @ref{Compile Assemble and Link from Source Code,, {Compile, Assemble, and Link from Source Code}}, and Using GCC in GNUPro Compiler Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
cpp, the GNU Preprocessor
cpp, a C-compatible macro preprocessor, works with the GNU
Compiler Collection 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 prints on
stdout.
The C preprocessor provides the following separate facilities:
There are two convenient options to assemble handwritten files that
require C-style
preprocessing. Both options depend on using the compiler driver
program, gcc, instead of directly calling the assembler.
.S (capitalized),
rather than .s (this indicates that the file is in assembly
language requiring C-style preprocessing).
For more information on cpp, see The C Preprocessor in
GNUPro Compiler Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
as, the GNU Assembler
as, the GNU assembler, translates text-based assembly language
source files into binary-based object files. Normally it operates
without you being aware of it, as the compiler driver program
(gcc) will invoke it automatically. If, however, you are
creating your own assembler source files then you will need to invoke it
directly.
If, while using gcc you want to pass special command line options
to the assembler to control its' behavior, you will need to use the
`-Wa,<text>' command line option. This option passes
<text> directly on to the assembler's command line. For example:
gcc -c -g -O -Wa,-alh,-L file.c |
passes the `-alh' command line option on to the assembler. (This will cause the assembler to emit a listing file which shows the assembler source generated by the compiler for each line of the C source file file .c).
For more information, see Using as in GNUPro Auxiliary
Development Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The assembler creates
object files, which, by convention, have the extension .o. These
are binary files that contain the assembled source code, information to
help the linker integrate the object file into an executable program,
debugging information and tables of all of the symbols used in the
source code.
Special programs exist to manipulate object files. For example
objdump
can disassemble an object file back into assembler source code, and ar
can group together multiple object files into an archive or library file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Assembler directives are commands inside the assembler source files that control how the object file is generated. They are also known as pseudo-ops or pseudo-operations because they can look like commands in the assembler programming language.
Assembler directives always start with a period (.). The rest of
their name is letters, usually in lower case. They have a wide range of
different uses, such as specifying alignments, inserting constants into
the output, and selecting in which sections of the output file the
assembled machine instructions will be placed.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ld, the GNU Linker
The GNU linker, ld
combines multiple object files together and creates an executable
program from them. It does this by resolving references between the
different object files, grouping together similar sections in the
object files into one place, arranging for these sections to be loaded
at the correct addresses in memory, and generating the necessary
header information at the start of a file that allows it to be run.
The linker moves blocks of bytes of your program to their load-time addresses. These blocks slide to their addresses as rigid units; their length does not change and neither does the order of the bytes within them. Such a rigid unit is called a section. 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.
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 allocatable, meaning that space should be reserved for it in memory when the executable starts runnihg. A section may also be marked as loadable, meaning that its contents should be loaded into memory when the executable starts. A section which is allocatable but not loadable will have a zero-filled area of memory created for it.
A section, which is neither loadable nor allocatable, typically contains
some sort of debugging information. Every loadable or allocatable
output section has two
addresses associated with it. The first is the virtual memory
address
(VMA), the address the section will have when the executable is
running. The second is the load memory address
(LMA), which is the address in memory where the section will loaded.
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 this
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. 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, which 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 is controlled by a linker script which is a text file containing commands in a simple language. The main purpose of the script is to describe how sections in the input files should be mapped into sections in 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 Linker Scripts.
The linker will use a default script that compiles into the linker
executable, if you do not supply one via the -T command line
option. Use the --verbose option to display the default linker
script. Certain options (such as -r or -N) will affect
the default linker script. Linker scripts are written in a superset
of AT&T's Link Editor Command Language syntax.
For more information, see Using ld in GNUPro
Development Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
gcov, the Test Coverage Tool
gcov, the code coverage/basic block profile display tool, allows
you to analyze the basic block profile of your program by recording how
often each basic block is executed. This information allows you to
determine the sections of code on critical paths and the code blocks
that are not executed at all.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB, the GNU debugger, has the principal purpose of allowing
you to stop your
program before it terminates. If your program terminates, the debugger
helps you determine where it failed. For working with the debugger,
with a command line approach, you first compile a file.c
file, using gcc -g file.c as a command, where
`-g' produces the debugging information; you then run the
debugger. See Debug the Executable, for the steps involved in
debugging.
Set breakpoints with the breakpoint command.
Navigate through the program with the step command or the
next command.
The debugger debugs threads, signals, trace information, and other data in a program. Each time your program performs a function call, a block of data (the stack frame), which shows the location of the call, the arguments, and the local variables of the function is generated. The debugger allows you to examine the stack frame to get your program to work.
For more information, see Debugging with GDB in GNUPro Debugger Tools. See also {Insight}, Debugging with Insight, and Insight, the GNUPro Debugger GUI Interface in GNUPro Debugger Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Besides the standard command line based debugger, GNUPro Toolkit includes Insight, a graphical user interface. Insight works on a range of host systems and target microprocessors, allowing development with complete access to the program state, for source and assembly level, with the ability to manage breakpoints, variables, registers, memory, threads and other functionality. Adding a series of intuitive views into the debugging process, Insight provides you with a wide range of system information.
See figure @xref{Figure A composite view of working with Insight,, A composite view of working with Insight}, for an example of the windows that Insight provides for analyzing and debugging programs.
For developing with Insight, see Debugging with Insight.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
make, the GNU Recompiling Tool
make, the GNU recompiling tool,
determines automatically which pieces of a large program you need to
recompile and then issues commands to recompile them. make
conforms to IEEE Standard 1003.2-1992 (POSIX.2) and is
compatible with any programming language whose compiler can run with
command line input from a shell. make is not limited only to
building programs; it can be used for any task in which some files must
update automatically whenever associated files 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 program,
typically, 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.
make 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 data base of
the makefile. The makefile has rules
which explain how and when to remake certain files that are the targets
of a particular rule. A simple makefile rule has the following form:
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, 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
activated by make wnen dependancy has changed. A rule may
have more than one command, with each command on its own line. 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. 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.
example 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 the example, 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.
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. You must
first update any dependencies that automatically generate. In
example 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 tabulation 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 information, see Using make in GNUPro
Development Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
newlib & libstdc++, the C & C++ Libraries
newlib
and libstdc++, the C and C++ libraries, serve as a collection of
subroutines and functions in compiled form, which link with a program
to form a complete executable, linking either statically or, with some
systems, dynamically.
newlib includes the GNU C
library, libc,
and the GNU C math library, libm
See GNUPro C Library and GNUPro C Math Library
for newlib functions in GNUPro Libraries.
libstdc++ is based on the ISO 14882 Standard C++ Library, with
all its compliant classes and functions. See
http://sources.redhat.com/libstdc++/links.html for the
libstdc++ library documentation.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
binutils, the GNU Binary Utilities
binutils, the GNU binary utilities, are
available on all hosts. They include ar, nm,
objcopy, objdump, ranlib,
size, strings, and strip.
For targets which use the ELF file format there is also a tool called
readelf.
There are three binary utilities, addr2line, windres,
and dlltool, which are for use with Cygwin, the porting layer
application for Win32 development.
The most important of the binary utilities are
objcopy
and
objdump.
objcopy is a tool to convert object and executable files. It can
add and remove sections and symbols, but the most commonly used feature
is it ability to change the file format. For example, it can convert an
ELF or COFF format executable into an S-record or Intel I-Hex format
file. These two formats are often used in building ROM images for
standalone and embedded systems. For more information, see
objcopy Utility in Using binutils in GNUPro
Auxiliary Development Tools.
objdump is a tool to display information about the contents of an
object or executable file. It can display symbol tables and section
headers and it can also act as a disassembler. Objdump also
knows about archives and libraries and can be used to display
information on all of the object files inside them. For more
information, see objdump Utility in Using binutils
in GNUPro Auxiliary Development Tools.
A few of the more useful options for objdump are: `-h' (to
display section headers), `-t' (to display symbols), `-p' (to
display private header information) and `-d'
for assembler (to display a disassembly). `-d' will normally
only disassemble sections that are expected to contain instructions. To
disassemble all sections use `-D' instead. The option
`--prefix-addresses' can be used to print a complete address on
each line of the disassembler's output.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Cygwin, a full-featured Win32
porting layer for
UNIX applications, is compatible with all Win32 hosts (currently, these
are Microsoft
Windows NT/95/98/2000 systems). Cygwin makes all directories have
similar behavior to a UNIX system, with all the UNIX default tools in
their familiar place. Available scripting languages include
bash, tsh, and tcsh. Tools such as Perl, Tcl/Tk,
sed, awk, vim, Emacs, xemacs, telnetd and
ftpd work in Cygwin.
In order to emulate a UNIX kernel and access all processes that can run with it, use the Cygwin DLL (dynamically linked library). The Cygwin DLL will create shared memory areas so that other processes using separate instances of the DLL can access the kernel. Using DLLs with Cygwin, yo can link into your program at run time instead of build time. The following documentation describes the three parts of a DLL and their usage.
.dll
file makes available to other programs as a list of global
symbols, with the rest of the contents hidden. Create this list with a
text editor; it's also possible to do it automatically from the list of
functions in your code. The dlltool utility creates the exports
section of the .dll file from your text file of exported symbols.
.dll file; they are not put into a .exe file.
.a library, containing
the vital information for the operating system and the program to interacts
as it or imports the
.dll as data, linking the data into an .exe file, all generated
by the dlltool
utility.
The following
example shows the use of the compile command with gcc,
demonstrating how to build a .dll file, using a single
myprog.c file, for a myprog .exe program,
with a single mydll.c file, for the contents of a
.dll file, with the resulting mydll .dll file then
compiling everything as objects.
gcc -c myprog.c gcc -c mydll.c |
For more information, find the ~/cygwin/doc directory to locate
documentation discussing use of the GNU development tools with a Win32
host and exploring the architecture of the Cygwin library; see also
http://sources.redhat.com/cygwin/.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
info, the Documentation Tools
info provides the sources for documentation for the GNU tools; it
requires the following tools, including the TeX tools.
texindex,
texi2dvi, the standard GNU documentation formatting tools.
makeinfo, info, the GNU online documentation tools.
man page s, the GNU documentation on all the tools and
programs in this release.
gprof, details of the GNU performance analyzer (only
for some systems).
You have the freedom to copy the documentation using its accompanying copyright statements, which include necessary permissions. To get the documentation in HTML or printable form, see http://www.fsf.org/doc/doc.html and http://www.fsf.org/doc/other-free-books.html.
See Using info in GNUPro Auxiliary
Development Tools for documentation regarding these tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
info Documentation
Browse through the documentation using either Emacs or the info
documentation browser program. The information is in nodes,
corresponding to the sections of a printed book. Follow them in
sequence, as in books, or, using the hyperlinks, find the node that has
the information you need. info has hot references (if one
section refers to another section, info takes you directly to
that other section while allowing you to return easily to where you had
been). You can also search for particular words or phrases. After
installing GNUPro Toolkit, use info by typing its name at a shell
prompt; no options or arguments are necessary. Check that info
is in your shell path after you install GNUPro Toolkit. If you have
problems running info, contact your system administrator.
To get help with using info, type h for a programmed
instruction sequence, or Ctrl + h for a short summary of commands. To
stop using info, type q.
See Reading info Files in Using info in
GNUPro Auxiliary Development Tools for detailed references for
the info tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
See http://www.redhat.com/docs/manuals/gnupro/ for more information about the tools. For help with using the tools, see Developing with GNUPro Toolkit.
To learn about rebuilding sources for the tools, see
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |