|Red Hat Docs > Manuals > EDK Manuals >|
Embedded DevKit combines the latest open-source development tools from Red Hat, allowing you to set up and manage an entire embedded environment between a host operating system and a target processor board. Within the IDE is an infrastructure of the GNU compiler, the GNU debugger, the GNU utilities, the GNU libraries and the world's most advanced browsing and source code comprehension tools. With these tools, you can interpret code structures and relationships, and more easily enable migrating, re-engineering, reusing code, or understanding problems for creating applications.
The following documentation details these source tools.
See PowerPC Target-Specific issues and x86 Target-Specific Issues for target-specific issues.
gcc, the GNU C Compiler
gcc, the GNU compiler, produces assembly language code from processed C files. For more information, see Using GNU CC in GNUPro Compiler Tools. gcc invokes the necessary GNU compiler passes for you with the following utilities.
The preprocessor which processes all the header files and macros that your target requires. cpp merges in the #include files, expands all macros definitions, and processes the #ifdef sections. To see the output of cpp, invoke gcc with the -E option, and the preprocessed file will print on stdout. 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 calling the assembler directly.
The assembler which produces binary code from the assembly language code and puts it in an object file. gas can be useful as either a compiler pass or a source-level assembler. gas emits a relocatable object file from the assembly language source code. The object file contains the binary code and the debug symbols.
There are several important machine-independent compiler switches, among which are -fno-exceptions (for C++), -frtti (for C++) and -T (for linking).
You have four implicit file extensions: .c, .C, .s, and .S.
g++, the GNU C++ Compiler
When you compile C or C++ programs with GNU C, the compiler quietly inserts a call at the beginning of main to a gcc support subroutine called __main. Normally this is invisible--run __main, if you want to avoid linking to the standard libraries, by specifying the compiler option, -nostdlib . Include -lgcc at the end of your compiler command line to resolve this reference. This links with the compiler support library libgcc.a
. Putting it at the end of your command line ensures that you have a chance to link first with any of your own special libraries. __main is the initialization routine for C++ constructors. Because GNU C is designed to interoperate with g++, the GNU C++ compiler, even C programs must have this call; otherwise, C++ object files linked with a C main might fail. g++ is a program that calls GNU CC with the default language set to C++, and automatically specifies linking against libstdc++, the GNU class library.
For more details on gcc and g++, see Using GNU CC in GNUPro Compiler Tools.
gdb, the Debugging Tool
To run gdb , use a command line interface from a shell with ' gdb' as input. Be sure that you are using the correct path to the gdb tool. See also Debugging with GDB in GNUPro Debugging Tools. The following routines are useful for debugging a project on native host operating systems, although not on target operating systems.
To run gdb on an embedded target, connect to the target executable using the gdbserver tool from Insight. gdbserver is a small special-purpose tool running on the target executable which controls its execution. gdb connects to the gdbserver using either a serial or an Ethernet (TCP/IP) connection (see Debug an Executable Application on a Target Board). Ensure that the path is set correctly from the IDE, or by connecting directly with Insight (see Working with Insight, the Debugger Interface).
Insight enables embedded technology development to be more efficient while supporting a range of host systems and target microprocessors. Insight allows development with complete access to the program state, including a series of intuitive views into the debug process, providing the developer with a wide range of system information. For more information on developing with Insight, see Developing for Embedded Systems and Working with Insight, the Debugger Interface.
libstdc++, the GNU Libraries
The Embedded DevKit IDE contains libc , the GNU C library, libm , the GNU C math library (see GNUPro Libraries) and libstdc++, the C++ library (see http://sourceware.cygnus.com/libstdc++/ ).
binutils, the GNU Binary Utilities
The binary utilities that are available include addr2line, ar, c++filt, dlltool, nlmconv, nm, objcopy, objdump, ranlib, readelf, size, strings, strip, and windres. The most important of the binary utilities are objcopy and objdump. For more information on binutils, see Using binutils in GNUPro Utilities.
in the previous example's input is the executable binary filename, and
is the filename for the S-record. Most PROM burners
also read S-records or some similar format. For more information
on S-records, see the discussions for
Copies and translates object files. A few ROM monitors that load executable binary images, such as a.out , must, consequently, load an S-record. An S-record is a printable ASCII representation of an executable binary image. S-records are suitable both for building ROM images for standalone boards and for downloading images to embedded systems. Use the following input for example.
objcopy -O srec infile outfile
infile in the previous example's input is the executable binary filename, and outfile is the filename for the S-record. Most PROM burners also read S-records or some similar format. For more information on S-records, see the discussions for FORMAT output-format in Using ld in GNUPro Utilities.For more discussion of making an executable binary image, see "objcopy utility" in Using binutils in GNUPro Utilities.
For disassembling, prints the complete address on each line, starting each output line with the address it's disassembling. This is the older disassembly format. Otherwise, you only get raw opcodes.
The following documentation discusses the PowerPC target-specific issues. Cross-development tools normally install with names that reflect the target, so that you can install more than one set of tools in the same binary directory. Use the target name as a prefix to the program name that you are calling, constructing the callwith the --target option to configure. For example, call gcc using powerpc-elix-linux-gnu-gcc.
For PowerPC targets, when you run gcc , you can use command line options to choose whether to take advantage of the extra PowerPC machine instructions, and whether to generate code for hardware or software floating point, or other target-specific details.-mpower
Use these options to specify which instructions are available on the processor you are using. The default value of these options is determined when configuring gcc. Specifying -mcpu=cpu_type overrides the specification of these options. We recommend you use -mcpu=cpu_type rather than any of these options.
The -mpower option allows gcc to generate instructions that are found only in the POWER architecture and to use the MQ register. Specifying -mpower2 implies -power and also allows gcc to generate instructions that are present in the POWER2 architecture but not the original POWER architecture.
The -mpowerpc option allows gcc to generate instructions that are found only in the 32-bit subset of the PowerPC architecture. Specifying -mpowerpc-gpopt implies -mpowerpc and also allows gcc to use the optional PowerPC architecture instructions in the General Purpose group, including floating-point square root. Specifying -mpowerpc-gfxopt implies -mpowerpc and also allows gcc to use the optional PowerPC architecture instructions in the Graphics group, including floating-point select.-mnew-mnemonics
Selects which mnemonics to use in generated assembler code. mnew-mnemonics requests output that uses the assembler mnemonics defined for the PowerPC architecture, while -mold-mnemonics requests the assembler mnemonics defined for the POWER architecture. Instructions defined in only one architecture have only one mnemonic; gcc uses that mnemonic irrespective of which of these options that you use. PowerPC assemblers support both the old and new mnemonics, as will later POWER assemblers. Current POWER assemblers only support the old mnemonics. Specify -mnew-mnemonics if you have an assembler that supports them, otherwise specify -mold-mnemonics. The default value of these options depends on how you configured gcc. Specifying -mcpu-cpu_type sometimes overrides the value of the option. To build a cross-compiler, you should normally not specify either -mnew-mnemonics or -mold-mnemonics; instead, accept the default.-mcpu=cpu_type
Sets architecture type, register usage, choice of mnemonics, and instruction scheduling parameters for machine type, 860.-mmpc860c0[=N]
Only applicable to MPC860 chips when producing ELF executables with the GNU linker. While not changing .o files, this option only causes the linker to perform a check for problematic conditional branches by implementing a work around. The problem is that some chips may treat the target instruction as a no-op, given the following conditions:
Sets the instruction scheduling parameters for machine type, cpu_type , but does not set the architecture type, register usage, choice of mnemonics like -mcpu=cpu_type would. The same values for cpu_type are used for -mtune= cpu_type as for -mcpu= cpu_type. The -mtune= cpu_type option overrides the -mcpu= cpu_type option in terms of instruction scheduling parameters.-mfull-toc
Modifies generation of the TOC (Table Of Contents), which is created for every executable file. The -mfull-toc option is default; in that case, gcc will allocate at least one TOC entry for each unique non-automatic variable reference in your program. gcc will also place floating-point constants in the TOC. However, only 16,384 entries are available in the TOC.
If you receive a linker error message saying that you have overflowed the available TOC space, reduce the amount of TOC space used with the -mno-fp-in-toc and -mno-sum-in-toc options. -mno-fp-in-toc prevents gcc from putting floating-point constants in the TOC and -mno-sum-in-toc forces gcc to generate code to calculate the sum of an address and a constant at run-time instead of putting that sum into the TOC. Specify one or both of these options; each causes gcc to produce very slightly slower and larger code at the expense of conserving TOC space.
If you still run out of space in the TOC even when you specify both of these options, specify -mminimal-toc instead, causing gcc to make only one TOC entry for every file; when you specify this option, gcc will produce code which is slower and larger but which uses extremely little TOC space. You may wish to use this option only on files that contain less frequently executed code.-msoft-float
-msoft-float generates code that does not use and -mhard-float generates code that does use the floating-point register set. Software floating point emulation is provided if you use the -msoft-float option, and if you pass the option to gcc when linking.-mmultiple
-mmultiple generates code that uses and -mno-multiple generates code that does not use the load multiple word instructions and the store multiple word instructions. These instructions are generated by default on POWER systems, and not generated on PowerPC systems. Do not use -mmultiple on little endian PowerPC systems, since those instructions do not work when the processor is in little endian mode.-mstring
-mstring generates code that uses and -mno-string generates code that does not use the load string instructions and the store string word instructions to save multiple registers and do small block moves. These instructions are generated by default on POWER systems, and not generated on PowerPC systems.-mupdate
-mupdate generates code that uses and -mno-update generates code that does not use the load or store instructions that update the base register to the address of the calculated memory location. These instructions are generated by default. If you use -mno-update, there is a small window between the time that the stack pointer is updated and the address of the previous frame is stored, which means code that walks the stack frame across interrupts or signals may get corrupted data.-mfused-madd
-mfused-madd generates code that uses and -mno-fused-madd generates code that does not use the floating point multiply and accumulate instructions. These instructions are generated by default if hardware floating is used.-mno-bit-align
On embedded PowerPC systems, -mno-bit-align does not and -mbit-align does force structures and unions containing bit fields aligned to the base type of the bit field. For example, by default a structure containing nothing but eight unsigned bitfields of length one would be aligned to a four byte boundary and would have a size of four bytes. By using -mno-bit-align, the structure would be aligned to a one byte boundary and be one byte in size.-mno-strict-align
On embedded PowerPC systems -mno-strict-align do not and -mstrict-align do assume that unaligned memory references will be handled by the system.-mrelocatable
On embedded PowerPC systems, -mrelocatable generates code that allows and -mno-relocatabl generates code that does not allow the program to be relocated to a different address at runtime. If you use -mrelocatable on any module, all objects linked together must be compiled with -mrelocatable or -mrelocatable-lib.-mrelocatable-lib
On embedded PowerPC systems, -mrelocatable-lib generates code that allows and -mno-relocatable-lib generates code that does not allow the program to be relocated to a different address at runtime. Modules compiled with -mreloctable-lib can be linked with either modules compiled without -mrelocatable and -mrelocatable-lib or with modules compiled with the -mrelocatable options.-mno-toc
On embedded PowerPC systems, -mno-toc does not and -mtoc does assume that register two has a pointer to a global area pointing to addresses used in the program.-mno-traceback
On embedded PowerPC systems, -mno-traceback does not and -mtraceback does generate a trace-back tag before the start of the function. This tag can be used by the debugger to identify the start of a function.-mlittle
On embedded PowerPC systems, -mlittle compiles codes for the processor in little endian mode. -mlittle-endian is the same as -mlittle.-mbig
On embedded PowerPC systems, -mbig compiles code for the processor in big endian mode. -mbig-endian is the same as -mbig.-mcall-sysv
On embedded PowerPC systems, compiles codes using calling conventions that adhere to the March 1995 draft of the System V Application Binary Interface, PowerPC processor supplement.-mcall-linux
On embedded PowerPC systems, compiles code for the Linux operating system.-mprototype
On embedded PowerPC systems, assumes that all calls to variable argument functions are properly prototyped; otherwise, the compiler must insert an instruction before every non-prototyped call to set or clear bit 6 of the condition code register to indicate whether floating point values were passed in the floating point registers in the case that the function takes a variable arguments.-mmvme
On embedded PowerPC systems, assumes that the startup module is called mvme-crt0.o, and libmvme.a and libc.a are the standard C libraries.-memb
On embedded PowerPC systems, sets the PPC_EMB bit in the ELF flags header to indicate that eabi extended relocations are used.-mads
On embedded PowerPC systems, assumes that the startup module is called crt0.o and libads.a and libc.a are the standard C libraries.-msdata-data
On embedded PowerPC systems, puts small global and static data in the .sdata section. Also puts small uninitialized global and static data in the .sbss section. Do not use register r13 to address small data. This is the default behavior unless other -msdata options are used.-msdata=none
On embedded PowerPC systems, -msdata=none puts all initialized global and static data in the .data section, and all uninitialized data in the .bss section.-G num
On embedded PowerPC systems, puts global and static items less than or equal to num bytes into the small data or bss sections instead of the normal data or bss section. By default, num is 8. -G num is also passed to the linker. All modules should be compiled with the same -G num value.-mregnames
For the size and alignment for all data types for PowerPC targets, see Data type sizes and alignments for PowerPC targets.Data type sizes and alignments for PowerPC targets
Data type sizes and alignments for PowerPC targets defines the alignment within aggregates (structures and unions), with padding added if necessary. Aggregates have alignment equal to that of their most aligned member. Aggregates have sizes that are a multiple of their alignment.
For the calling conventions for subroutine calls for PowerPC targets, see Parameter registers for PowerPC targets for the parameters of registers.Parameter registers for PowerPC targets
See Register usage for PowerPC targets for other register usage.Register usage for PowerPC targets
Bit 6 of cr1 is set if a variable argument function is passed floating-point arguments in registers. Unless -mregparm is used, all arguments are pushed on the stack, the first argument at the lower address.
Data types and register usage for return values for PowerPC targets shows the data types and register usage for function return values for PowerPC targets.Data types and register usage for return values for PowerPC targets
Structures and unions that fit into two general-purpose registers are returned in r3, or in r3 and r4, if necessary. The caller handles larger structures and unions by passing, as a hidden first argument, a pointer to space allocated to receive the return value.
See Stack frames for functions taking a fixed number of arguments for PowerPC targets about stack frames for functions taking a fixed number of arguments.
In Stack frames for functions taking a fixed number of arguments for PowerPC targets, frame pointer (FP) points to the same location as stack pointer (SP).
See Stack frames for functions that take a variable number of arguments for PowerPC targets about stack frames for functions taking a variable number of arguments.
Aggregates larger than eight bytes are returned by having the caller pass the address of a buffer to hold the value in r0 as an invisible first argument. All arguments are then shifted down by one; the address of this buffer is returned in r0.-mgas
Compiles using gas to assemble gcc output.-Wa
Passes arguments through to the assembler, if you invoke gas through gcc. One common use of this option is to exploit gas's listing features. Assembler arguments that you specify with gcc -Wa must be separated from each other (and the -Wa) by commas, like the options, -alh and -L in the following example input.
Preserves local labels, to make the listing output more intelligible to humans. For example, in the following command line input, the assembler option, -ahl, requests a listing with interspersed high-level language and assembly language.powerpc-elix-linux-gnu -c -g -O -Wa,-alh,-L file.c
Use the following listing-control assembler directives to control the appearance of the listing output (if you do not request listing output with one of the -a options, the following listing-control directives have no effect).
Describes the page size for your output (the default is 60, 200). gas generates form feeds after printing each group of linecount lines. To avoid these automatic form feeds, specify 0 as linecount. The variable input for columnwidth uses the same descriptive option.
There are 32 32-bit general (integer) registers: r0 through r31. There are 32 64-bit floating-point registers: f0 through f31. The compiler will generate code, using numbers 0 through 31 to represent general-purpose registers. Use the symbols in Symbol aliases for PowerPC target-specific registers as aliases for individual registers.Symbol aliases for PowerPC target-specific registers
PowerPC target-specific register shows the PowerPC target-specifc registers that the GNU tools use.PowerPC target-specific register
The assembler directives for the PowerPC targets are: .abicalls, .abort, .aent, .align, .appfile, .appline, .ascii, .asciiz, .asciz, .balign, .balignl, .balignw, .bgnb, .bss, .byte, .comm, .common, .common.s, .cpadd, .cpload, .cprestore, .data, .dc, .dc.b, .dc.d, .dc.l, .dc.s, .dc.w, .dc.x, .dcb, .dcb.b, .dcb.d, .dcb.l, .dcb.s, .dcb.w, .dcb.x, .debug, .double, .ds, .ds.b, .ds.d, .ds.l, .ds.p, .ds.s, .ds.w, .ds.x, .dword, .eject, .else, .elsec, .end, .endb, .endc, .endif, .ent, .equ, .equiv, .err, .exitm, .extern, .fail, .file, .fill, .float, .fmask, .format, .frame, .global, .globl, .gpword, .half, .hword, .if, .ifc, .ifdef, .ifeq, .ifeqs, .ifge, .ifgt, .ifle, .iflt, .ifnc, .ifndef, .ifne, .ifnes, .ifnotdef, .include, .insn, .int, .irep, .irepc, .irp, .irpc, .lcomm, .lflags, .linkonce, .list, .llen, .loc, .long, .lsym, .macro, .mask, .mexit, .mri, .name, .noformat, .nolist, .nopage, .octa, .offset, .option, .org, .p2align, .p2alignl, .p2alignw, .page, .plen, .print, .psize, .purgem, .quad, .rdata, .rep, .rept, .rva, .sbttl, .sdata, .set, .short, .single, .skip, .space, .spc, .stabd, .stabn, .stabs, .string, .struct, .text, .title, .ttl, .verstamp, .word, .xcom, .xdef, .xref, .xstabs, .zero.
The following documentation discusses the x86 target-specific issues. Cross-development tools normally install with names that reflect the target, so that you can install more than one set of tools in the same binary directory. Use the target name as a prefix to the program name that you are calling, constructing the callwith the --target option to configure. For example, call gcc using i686-elix-linux-gnu-gcc.
For a complete list of available generic compiler options, see "GNU CC Command Options" in Using GNU CC in GNUPro Compiler Tools. In addition, the following x86 target-specific command line options are supported.-mintel-syntax
Generates Intel syntax, instead of AT&T/Unixware syntax, assembly language.-msoft-float
Causes the compiler to generate output containing library calls for floating point operations. On by default.-mrtd
Uses callee-pops argument calling conventions.-malign-double
Aligns doubles on 8-byte boundries.-mno-fp-ret-in-387
Returns values of functions in FPU registers.-mno-fancy-math-387
Doesn't allow use of sin, cos, sqrt and the other advanced math instructions.-momit-leaf-frame-pointer
Omits a frame pointer from leaf functions.-mcpu=x86
Schedules code, substituting x86 for the one of the following CPUs: i386, i486, i586, i686.-march= x86
Generates code, substituting x86 for the one of the following CPUs: i386, i486, i586; none of the CPUs is backward compatible.-mregparm= N
Passes N registers in arguments (where N is an integer from 0 to 3).-malign-jumps= N
Sets alignment for element to 2 to the power of 'N '.
For more information, see "Declaring Attributes of Functions" and "Specifying Attributes of Variables" in "Extensions to the C Language Family" in Using GNU CC in GNUPro Compiler Tools for more information.
For the size and alignment for all data types for x86 targets, see Data type sizes and alignments for x86 targets.Data type sizes and alignments for x 86 targets
Data type sizes and alignments for x86 targets defines the alignment within aggregates (structures and unions), with padding added if necessary. Aggregates have alignment equal to that of their most aligned member. Aggregates have sizes that are a multiple of their alignment.Parameter registers for x86 targets
See Data types and register usage about data types and register usage for return values for x86 targets.Data types and register usage for return values
Stack frames for functions have the functionality as Stack frame for x86 shows, where EBP and ESP are register names (EBP stands for extended base pointer; ESP stands for extended stack pointer).
See Register names for the register naming conventions.Register names
The x86 target boards use the following assembler directives: .abort, .align, .ascii, .asciiz, .asciz, .balign, .balignl, .balignw, .bgnb, .bss, .byte, .comm, .common, .common.s, .data, .dc, .dc.b, .dc.d, .dc.l, .dc.s, .dc.w, .dc.x, .dcb, .dcb.b, .dcb.d, .dcb.l, .dcb.s, .dcb.w, .dcb.x, .double, .ds, .ds.b, .ds.d, .ds.l, .ds.p, .ds.s, .ds.w, .ds.x, .dword, .eject, .else, .elsec, .end, .endb, .endc, .endif, .ent, .equ, .equiv, .err, .exitm, .extern, .fail, .file, .fill, .float, .format, .global, .globl, .half, .hword, .if, .ifc, .ifdef, .ifeq, .ifeqs, .ifge, .ifgt, .ifle, .iflt, .ifnc, .ifndef, .ifne, .ifnes, .ifnotdef, .include, .int, .intel-syntax, .irep, .irepc, .irp, .irpc, .lcomm, .lflags, .linkonce, .list, .llen, .long, .lsym, .macro, .mexit, .name, .noformat, .nolist, .nopage, .octa, .offset, .option, .org, .p2align, .p2alignl, .p2alignw, .page, .plen, .print, .psize, .purgem, .quad, .rdata, .rep, .rept, .rva, .sbttl, .sdata, .set, .short, .single, .skip, .space, .spc, .stabd, .stabn, .stabs, .string, .struct, .text, .title, .ttl, .word, .xcom, .xdef, .xref, .xstabs, .zero.