GCC for Embedded Engineers

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):

"<path>/as.exe" "-mcpu=xscale" "-mfloat-abi=soft" 
 ↪"-o" "<temppath>/ccm4aB3B.o" "<temppath>/ccC39DVR.s"

The compiler has the following in the specs for the assembler:

*asm:
%{mbig-endian:-EB} %{mlittle-endian:-EL} %{mcpu=*:-mcpu=%*} 
 ↪%{march=*:-march=%*} %{mapcs-*:-mapcs-%*} 
 ↪%(subtarget_asm_float_spec) 
 ↪%{mthumb-interwork:-mthumb-interwork} 
 ↪%{msoft-float:-mfloat-abi=soft} 
 ↪%{mhard-float:-mfloat-abi=hard} %{mfloat-abi=*} 
 ↪%{mfpu=*} %(subtarget_extra_asm_spec)

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

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.

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

Force GCC to use an alternate C library:

armv5l-linux-gcc -nostdlib -nostdinc -isystem 
 ↪<path to header files> -L<path to c library> 
 ↪-l <c library file>

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.

Mixed assembler/source output:

armv5l-linux-gcc -g program.c -o binary-program
armv5l-linux-objdump -S binary-program

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:

armv5l-linux-gcc -### program.c &> compile-commands