GCC for Embedded Engineers

Read along to understand how GCC works, find out what all those other programs in the toolchain directory do, and learn some tips and tricks to become more comfortable with most indispensable tool in your project.

The spec File

Recall that GCC is a driver program that knows what program to invoke
to build a certain output, which begs the question, “How does it know
that?”
This information that was built in to GCC when it was built is kept in
the “specs”. To see the specs, run GCC with the -dumpspecs parameters:

armv5l-linux-gcc -dumpspecs

The console will fill with a few hundred lines of output. The spec file
format evolved over years of development, and it's easier for the computer to
read than for a person. Each line contains instructions for what parameters
to use for a given tool. From the prior example, consider the command
line for the assembler (with the path names removed for readability):

This line uses some familiar constructs explained below.
Adequately discussing the minutiae of the spec file would require an
article series in itself.

*asm: this line tells GCC the following line will override the
internal specification for the asm tool.

%{mbig-endian:-EB}: the pattern
%{symbol:parameter} means if a symbol was passed to GCC, replace it with
parameter; otherwise, this expands to a null string. In our example, the
parameter -mfloat-abi=soft was added this way.

%(subtarget_extra_asm_spec): evaluate the spec string %(specname). This may result in an empty
string, as it did in our case.

Most users don't need to modify the spec file for their compiler;
however, frequently engineers who inherit a project need to have GCC
recognize nonstandard extensions for files. For example, assembler
source files may have the extension, .arm; in this case, GCC won't know
what to execute, as it doesn't have a rule for that file extension. In
this case, you can create a spec file containing the following:

.arm:
@asm

and use the -specs=<file> to pass that to GCC, so that it will know how
to handle files with the .arm extension. The spec file on the command
line will be added to the internal spec file after it has been processed.

Tips and Tricks of the Trade

The following tips and tricks should be, if they haven't already,
stashed on the crib sheet of engineers who work with GCC.

This tells GCC to ignore everything it knows about where to find header
files and libraries and instead uses what you tell it. Most alternate
C libraries provide a script that performs this function; however,
some projects can't use the wrapper scripts, and other times, when
experimenting with several versions of a library, the flexibility and
control of specifying this information directly is necessary.

This is the best way to see exactly what GCC generated in relation to the input
code. Doing the compilation
with several different optimization settings shows what the compiler
did for the given optimization. Because embedded development pushes the
processor-support envelope, being able to see the generated assembler
code can be instrumental in proving a defect in GCC's support for that
processor. In addition, engineers can use this to validate that the
proper instructions are generated when specifying processor-specific
optimizations.

List predefined macros:

armv5l-linux-gcc -E -dM - < /dev/null

An invaluable tool for doing a port, this makes clear what GCC
macros will be set automatically and the value. This will show not only the
standard macros, but also all the ones set for the target architecture.
Keeping this output and comparing it to a newer version of GCC can save
hours of work when code fails to compile or run due to changes.

List dependencies:

armv5l-linux-gcc -M program.c

Formally, this command creates a separate make rule for each file on
the command line showing all dependencies. The output is indispensable
when trying to track down problems related to what header files a source
file is using and tracking down problems related to forcing GCC to use
an alternate C library. Deeply nested header files are both unavoidable
and incredibly useful in any nontrivial C project and can consume hours
when trying to debug. Using -MM instead of -M will show only nonsystem
dependencies—useful noise reduction when the problem resides in the
project files alone.

Show internal steps:

armv5l-linux-gcc -### program.c

This article already uses this command to make GCC show what steps occur
internally to build a program. When a program isn't compiling or linking
properly, using -### is the fastest route to see what GCC is doing.
Each command is on its own line and can be run individually, so:

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.