Options for Linking
These options come into play when the compiler links object files into
an executable output file. They are meaningless if the compiler is not
doing a link step.
object-file-name
A file name that does not end in a special recognized suffix is
considered to name an object file or library. (Object files are
distinguished from libraries by the linker according to the file
contents.) If linking is done, these object files are used as
input to the linker.
-c
-S
-E If any of these options is used, then the linker is not run, and
object file names should not be used as arguments.
-llibrary
-l library
Search the library named library when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified. Thus, foo.o -lz bar.o searches library z
after file foo.o but before bar.o. If bar.o refers to functions in
z, those functions may not be loaded.
The linker searches a standard list of directories for the library,
which is actually a file named liblibrary.a. The linker then uses
this file as if it had been specified precisely by name.
The directories searched include several standard system
directories plus any that you specify with -L.
Normally the files found this way are library files---archive files
whose members are object files. The linker handles an archive file
by scanning through it for members which define symbols that have
so far been referenced but not defined. But if the file that is
found is an ordinary object file, it is linked in the usual
fashion. The only difference between using an -l option and
specifying a file name is that -l surrounds library with lib and .a
and searches several directories.
-lobjc
You need this special case of the -l option in order to link an
Objective-C or Objective-C++ program.
-nostartfiles
Do not use the standard system startup files when linking. The
standard system libraries are used normally, unless -nostdlib or
-nodefaultlibs is used.
-nodefaultlibs
Do not use the standard system libraries when linking. Only the
libraries you specify will be passed to the linker. The standard
startup files are used normally, unless -nostartfiles is used. The
compiler may generate calls to "memcmp", "memset", "memcpy" and
"memmove". These entries are usually resolved by entries in libc.
These entry points should be supplied through some other mechanism
when this option is specified.
-nostdlib
Do not use the standard system startup files or libraries when
linking. No startup files and only the libraries you specify will
be passed to the linker. The compiler may generate calls to
"memcmp", "memset", "memcpy" and "memmove". These entries are
usually resolved by entries in libc. These entry points should be
supplied through some other mechanism when this option is
specified.
One of the standard libraries bypassed by -nostdlib and
-nodefaultlibs is libgcc.a, a library of internal subroutines that
GCC uses to overcome shortcomings of particular machines, or
special needs for some languages.
In most cases, you need libgcc.a even when you want to avoid other
standard libraries. In other words, when you specify -nostdlib or
-nodefaultlibs you should usually specify -lgcc as well. This
ensures that you have no unresolved references to internal GCC
library subroutines. (For example, __main, used to ensure C++
constructors will be called.)
-pie
Produce a position independent executable on targets which support
it. For predictable results, you must also specify the same set of
options that were used to generate code (-fpie, -fPIE, or model
suboptions) when you specify this option.
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that
support it. This instructs the linker to add all symbols, not only
used ones, to the dynamic symbol table. This option is needed for
some uses of "dlopen" or to allow obtaining backtraces from within
a program.
-s Remove all symbol table and relocation information from the
executable.
-static
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
-shared
Produce a shared object which can then be linked with other objects
to form an executable. Not all systems support this option. For
predictable results, you must also specify the same set of options
that were used to generate code (-fpic, -fPIC, or model suboptions)
when you specify this option.[1]
-shared-libgcc
-static-libgcc
On systems that provide libgcc as a shared library, these options
force the use of either the shared or static version respectively.
If no shared version of libgcc was built when the compiler was
configured, these options have no effect.
There are several situations in which an application should use the
shared libgcc instead of the static version. The most common of
these is when the application wishes to throw and catch exceptions
across different shared libraries. In that case, each of the
libraries as well as the application itself should use the shared
libgcc.
Therefore, the G++ and GCJ drivers automatically add -shared-libgcc
whenever you build a shared library or a main executable, because
C++ and Java programs typically use exceptions, so this is the
right thing to do.
If, instead, you use the GCC driver to create shared libraries, you
may find that they will not always be linked with the shared
libgcc. If GCC finds, at its configuration time, that you have a
non-GNU linker or a GNU linker that does not support option
--eh-frame-hdr, it will link the shared version of libgcc into
shared libraries by default. Otherwise, it will take advantage of
the linker and optimize away the linking with the shared version of
libgcc, linking with the static version of libgcc by default. This
allows exceptions to propagate through such shared libraries,
without incurring relocation costs at library load time.
However, if a library or main executable is supposed to throw or
catch exceptions, you must link it using the G++ or GCJ driver, as
appropriate for the languages used in the program, or using the
option -shared-libgcc, such that it is linked with the shared
libgcc.
-symbolic
Bind references to global symbols when building a shared object.
Warn about any unresolved references (unless overridden by the link
editor option -Xlinker -z -Xlinker defs). Only a few systems
support this option.
-T script
Use script as the linker script. This option is supported by most
systems using the GNU linker. On some targets, such as bare-board
targets without an operating system, the -T option may be required
when linking to avoid references to undefined symbols.
-Xlinker option
Pass option as an option to the linker. You can use this to supply
system-specific linker options which GCC does not know how to
recognize.
If you want to pass an option that takes a separate argument, you
must use -Xlinker twice, once for the option and once for the
argument. For example, to pass -assert definitions, you must write
-Xlinker -assert -Xlinker definitions. It does not work to write
-Xlinker "-assert definitions", because this passes the entire
string as a single argument, which is not what the linker expects.
When using the GNU linker, it is usually more convenient to pass
arguments to linker options using the option=value syntax than as
separate arguments. For example, you can specify -Xlinker
-Map=output.map rather than -Xlinker -Map -Xlinker output.map.
Other linkers may not support this syntax for command-line options.
-Wl,option
Pass option as an option to the linker. If option contains commas,
it is split into multiple options at the commas. You can use this
syntax to pass an argument to the option. For example,
-Wl,-Map,output.map passes -Map output.map to the linker. When
using the GNU linker, you can also get the same effect with
-Wl,-Map=output.map.
NOTE: In Ubuntu 8.10 and later versions, for LDFLAGS, the option
-Wl,-z,relro is used. To disable, use -Wl,-z,norelro.
-u symbol
Pretend the symbol symbol is undefined, to force linking of library
modules to define it. You can use -u multiple times with different
symbols to force loading of additional library modules.
Options for Directory Search
These options specify directories to search for header files, for
libraries and for parts of the compiler:
-Idir
Add the directory dir to the head of the list of directories to be
searched for header files. This can be used to override a system
header file, substituting your own version, since these directories
are searched before the system header file directories. However,
you should not use this option to add directories that contain
vendor-supplied system header files (use -isystem for that). If
you use more than one -I option, the directories are scanned in
left-to-right order; the standard system directories come after.
If a standard system include directory, or a directory specified
with -isystem, is also specified with -I, the -I option will be
ignored. The directory will still be searched but as a system
directory at its normal position in the system include chain. This
is to ensure that GCC's procedure to fix buggy system headers and
the ordering for the include_next directive are not inadvertently
changed. If you really need to change the search order for system
directories, use the -nostdinc and/or -isystem options.
-iquotedir
Add the directory dir to the head of the list of directories to be
searched for header files only for the case of #include "file";
they are not searched for #include, otherwise just like -I.
-Ldir
Add directory dir to the list of directories to be searched for -l.
-Bprefix
This option specifies where to find the executables, libraries,
include files, and data files of the compiler itself.
The compiler driver program runs one or more of the subprograms
cpp, cc1, as and ld. It tries prefix as a prefix for each program
it tries to run, both with and without machine/version/.
For each subprogram to be run, the compiler driver first tries the
-B prefix, if any. If that name is not found, or if -B was not
specified, the driver tries two standard prefixes, which are
/usr/lib/gcc/ and /usr/local/lib/gcc/. If neither of those results
in a file name that is found, the unmodified program name is
searched for using the directories specified in your PATH
environment variable.
The compiler will check to see if the path provided by the -B
refers to a directory, and if necessary it will add a directory
separator character at the end of the path.
-B prefixes that effectively specify directory names also apply to
libraries in the linker, because the compiler translates these
options into -L options for the linker. They also apply to
includes files in the preprocessor, because the compiler translates
these options into -isystem options for the preprocessor. In this
case, the compiler appends include to the prefix.
The run-time support file libgcc.a can also be searched for using
the -B prefix, if needed. If it is not found there, the two
standard prefixes above are tried, and that is all. The file is
left out of the link if it is not found by those means.
Another way to specify a prefix much like the -B prefix is to use
the environment variable GCC_EXEC_PREFIX.
As a special kludge, if the path provided by -B is [dir/]stageN/,
where N is a number in the range 0 to 9, then it will be replaced
by [dir/]include. This is to help with boot-strapping the
compiler.
-specs=file
Process file after the compiler reads in the standard specs file,
in order to override the defaults that the gcc driver program uses
when determining what switches to pass to cc1, cc1plus, as, ld,
etc. More than one -specs=file can be specified on the command
line, and they are processed in order, from left to right.
--sysroot=dir
Use dir as the logical root directory for headers and libraries.
For example, if the compiler would normally search for headers in
/usr/include and libraries in /usr/lib, it will instead search
dir/usr/include and dir/usr/lib.
If you use both this option and the -isysroot option, then the
--sysroot option will apply to libraries, but the -isysroot option
will apply to header files.
The GNU linker (beginning with version 2.16) has the necessary
support for this option. If your linker does not support this
option, the header file aspect of --sysroot will still work, but
the library aspect will not.
-I- This option has been deprecated. Please use -iquote instead for -I
directories before the -I- and remove the -I-. Any directories you
specify with -I options before the -I- option are searched only for
the case of #include "file"; they are not searched for #include
.
If additional directories are specified with -I options after the
-I-, these directories are searched for all #include directives.
(Ordinarily all -I directories are used this way.)
In addition, the -I- option inhibits the use of the current
directory (where the current input file came from) as the first
search directory for #include "file". There is no way to override
this effect of -I-. With -I. you can specify searching the
directory which was current when the compiler was invoked. That is
not exactly the same as what the preprocessor does by default, but
it is often satisfactory.
-I- does not inhibit the use of the standard system directories for
header files. Thus, -I- and -nostdinc are independent.
Specifying Target Machine and Compiler Version
The usual way to run GCC is to run the executable called gcc, or
-gcc when cross-compiling, or -gcc- to run a
version other than the one that was installed last. Sometimes this is
inconvenient, so GCC provides options that will switch to another
cross-compiler or version.
-b machine
The argument machine specifies the target machine for compilation.
The value to use for machine is the same as was specified as the
machine type when configuring GCC as a cross-compiler. For
example, if a cross-compiler was configured with configure arm-elf,
meaning to compile for an arm processor with elf binaries, then you
would specify -b arm-elf to run that cross compiler. Because there
are other options beginning with -b, the configuration must contain
a hyphen, or -b alone should be one argument followed by the
configuration in the next argument.
-V version
The argument version specifies which version of GCC to run. This
is useful when multiple versions are installed. For example,
version might be 4.0, meaning to run GCC version 4.0.
The -V and -b options work by running the-gcc-
executable, so there's no real reason to use them if you can just run
that directly.
Hardware Models and Configurations
Earlier we discussed the standard option -b which chooses among
different installed compilers for completely different target machines,
such as VAX vs. 68000 vs. 80386.
In addition, each of these target machine types can have its own
special options, starting with -m, to choose among various hardware
models or configurations---for example, 68010 vs 68020, floating
coprocessor or none. A single installed version of the compiler can
compile for any model or configuration, according to the options
specified.
Some configurations of the compiler also support additional special
options, usually for compatibility with other compilers on the same
platform.
ARC Options
These options are defined for ARC implementations:
-EL Compile code for little endian mode. This is the default.
-EB Compile code for big endian mode.
-mmangle-cpu
Prepend the name of the cpu to all public symbol names. In
multiple-processor systems, there are many ARC variants with
different instruction and register set characteristics. This flag
prevents code compiled for one cpu to be linked with code compiled
for another. No facility exists for handling variants that are
"almost identical". This is an all or nothing option.
-mcpu=cpu
Compile code for ARC variant cpu. Which variants are supported
depend on the configuration. All variants support -mcpu=base, this
is the default.
-mtext=text-section
-mdata=data-section
-mrodata=readonly-data-section
Put functions, data, and readonly data in text-section, data-
section, and readonly-data-section respectively by default. This
can be overridden with the "section" attribute.
-mfix-cortex-m3-ldrd
Some Cortex-M3 cores can cause data corruption when "ldrd"
instructions with overlapping destination and base registers are
used. This option avoids generating these instructions. This
option is enabled by default when -mcpu=cortex-m3 is specified.
ARM Options
These -m options are defined for Advanced RISC Machines (ARM)
architectures:
-mabi=name
Generate code for the specified ABI. Permissible values are: apcs-
gnu, atpcs, aapcs, aapcs-linux and iwmmxt.
-mapcs-frame
Generate a stack frame that is compliant with the ARM Procedure
Call Standard for all functions, even if this is not strictly
necessary for correct execution of the code. Specifying
-fomit-frame-pointer with this option will cause the stack frames
not to be generated for leaf functions. The default is
-mno-apcs-frame.
-mapcs
This is a synonym for -mapcs-frame.
-mthumb-interwork
Generate code which supports calling between the ARM and Thumb
instruction sets. Without this option the two instruction sets
cannot be reliably used inside one program. The default is
-mno-thumb-interwork, since slightly larger code is generated when
-mthumb-interwork is specified.
-mno-sched-prolog
Prevent the reordering of instructions in the function prolog, or
the merging of those instruction with the instructions in the
function's body. This means that all functions will start with a
recognizable set of instructions (or in fact one of a choice from a
small set of different function prologues), and this information
can be used to locate the start if functions inside an executable
piece of code. The default is -msched-prolog.
-mfloat-abi=name
Specifies which floating-point ABI to use. Permissible values are:
soft, softfp and hard.
Specifying soft causes GCC to generate output containing library
calls for floating-point operations. softfp allows the generation
of code using hardware floating-point instructions, but still uses
the soft-float calling conventions. hard allows generation of
floating-point instructions and uses FPU-specific calling
conventions.
Using -mfloat-abi=hard with VFP coprocessors is not supported. Use
-mfloat-abi=softfp with the appropriate -mfpu option to allow the
compiler to generate code that makes use of the hardware floating-
point capabilities for these CPUs.
The default depends on the specific target configuration. Note
that the hard-float and soft-float ABIs are not link-compatible;
you must compile your entire program with the same ABI, and link
with a compatible set of libraries.
-mhard-float
Equivalent to -mfloat-abi=hard.
-msoft-float
Equivalent to -mfloat-abi=soft.
-mlittle-endian
Generate code for a processor running in little-endian mode. This
is the default for all standard configurations.
-mbig-endian
Generate code for a processor running in big-endian mode; the
default is to compile code for a little-endian processor.
-mwords-little-endian
This option only applies when generating code for big-endian
processors. Generate code for a little-endian word order but a
big-endian byte order. That is, a byte order of the form 32107654.
Note: this option should only be used if you require compatibility
with code for big-endian ARM processors generated by versions of
the compiler prior to 2.8.
-mcpu=name
This specifies the name of the target ARM processor. GCC uses this
name to determine what kind of instructions it can emit when
generating assembly code. Permissible names are: arm2, arm250,
arm3, arm6, arm60, arm600, arm610, arm620, arm7, arm7m, arm7d,
arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710c,
arm7100, arm720, arm7500, arm7500fe, arm7tdmi, arm7tdmi-s, arm710t,
arm720t, arm740t, strongarm, strongarm110, strongarm1100,
strongarm1110, arm8, arm810, arm9, arm9e, arm920, arm920t, arm922t,
arm946e-s, arm966e-s, arm968e-s, arm926ej-s, arm940t, arm9tdmi,
arm10tdmi, arm1020t, arm1026ej-s, arm10e, arm1020e, arm1022e,
arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1156t2-s,
arm1176jz-s, arm1176jzf-s, cortex-a8, cortex-a9, cortex-r4,
cortex-r4f, cortex-m3, cortex-m1, xscale, iwmmxt, iwmmxt2, ep9312.
-mtune=name
This option is very similar to the -mcpu= option, except that
instead of specifying the actual target processor type, and hence
restricting which instructions can be used, it specifies that GCC
should tune the performance of the code as if the target were of
the type specified in this option, but still choosing the
instructions that it will generate based on the cpu specified by a
-mcpu= option. For some ARM implementations better performance can
be obtained by using this option.
-march=name
This specifies the name of the target ARM architecture. GCC uses
this name to determine what kind of instructions it can emit when
generating assembly code. This option can be used in conjunction
with or instead of the -mcpu= option. Permissible names are:
armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5e,
armv5te, armv6, armv6j, armv6t2, armv6z, armv6zk, armv6-m, armv7,
armv7-a, armv7-r, armv7-m, iwmmxt, iwmmxt2, ep9312.
-mfpu=name
-mfpe=number
-mfp=number
This specifies what floating point hardware (or hardware emulation)
is available on the target. Permissible names are: fpa, fpe2,
fpe3, maverick, vfp, vfpv3, vfpv3-d16 and neon. -mfp and -mfpe are
synonyms for -mfpu=fpenumber, for compatibility with older versions
of GCC.
If -msoft-float is specified this specifies the format of floating
point values.
-mstructure-size-boundary=n
The size of all structures and unions will be rounded up to a
multiple of the number of bits set by this option. Permissible
values are 8, 32 and 64. The default value varies for different
toolchains. For the COFF targeted toolchain the default value is
8. A value of 64 is only allowed if the underlying ABI supports
it.
Specifying the larger number can produce faster, more efficient
code, but can also increase the size of the program. Different
values are potentially incompatible. Code compiled with one value
cannot necessarily expect to work with code or libraries compiled
with another value, if they exchange information using structures
or unions.
-mabort-on-noreturn
Generate a call to the function "abort" at the end of a "noreturn"
function. It will be executed if the function tries to return.
-mlong-calls
-mno-long-calls
Tells the compiler to perform function calls by first loading the
address of the function into a register and then performing a
subroutine call on this register. This switch is needed if the
target function will lie outside of the 64 megabyte addressing
range of the offset based version of subroutine call instruction.
Even if this switch is enabled, not all function calls will be
turned into long calls. The heuristic is that static functions,
functions which have the short-call attribute, functions that are
inside the scope of a #pragma no_long_calls directive and functions
whose definitions have already been compiled within the current
compilation unit, will not be turned into long calls. The
exception to this rule is that weak function definitions, functions
with the long-call attribute or the section attribute, and
functions that are within the scope of a #pragma long_calls
directive, will always be turned into long calls.
This feature is not enabled by default. Specifying -mno-long-calls
will restore the default behavior, as will placing the function
calls within the scope of a #pragma long_calls_off directive. Note
these switches have no effect on how the compiler generates code to
handle function calls via function pointers.
-msingle-pic-base
Treat the register used for PIC addressing as read-only, rather
than loading it in the prologue for each function. The run-time
system is responsible for initializing this register with an
appropriate value before execution begins.
-mpic-register=reg
Specify the register to be used for PIC addressing. The default is
R10 unless stack-checking is enabled, when R9 is used.
-mcirrus-fix-invalid-insns
Insert NOPs into the instruction stream to in order to work around
problems with invalid Maverick instruction combinations. This
option is only valid if the -mcpu=ep9312 option has been used to
enable generation of instructions for the Cirrus Maverick floating
point co-processor. This option is not enabled by default, since
the problem is only present in older Maverick implementations. The
default can be re-enabled by use of the
-mno-cirrus-fix-invalid-insns switch.
-mpoke-function-name
Write the name of each function into the text section, directly
preceding the function prologue. The generated code is similar to
this:
t0
.ascii "arm_poke_function_name", 0
.align
t1
.word 0xff000000 + (t1 - t0)
arm_poke_function_name
mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4
When performing a stack backtrace, code can inspect the value of
"pc" stored at "fp + 0". If the trace function then looks at
location "pc - 12" and the top 8 bits are set, then we know that
there is a function name embedded immediately preceding this
location and has length "((pc[-3]) & 0xff000000)".
-mthumb
Generate code for the Thumb instruction set. The default is to use
the 32-bit ARM instruction set. This option automatically enables
either 16-bit Thumb-1 or mixed 16/32-bit Thumb-2 instructions based
on the -mcpu=name and -march=name options.
-mtpcs-frame
Generate a stack frame that is compliant with the Thumb Procedure
Call Standard for all non-leaf functions. (A leaf function is one
that does not call any other functions.) The default is
-mno-tpcs-frame.
-mtpcs-leaf-frame
Generate a stack frame that is compliant with the Thumb Procedure
Call Standard for all leaf functions. (A leaf function is one that
does not call any other functions.) The default is
-mno-apcs-leaf-frame.
-mcallee-super-interworking
Gives all externally visible functions in the file being compiled
an ARM instruction set header which switches to Thumb mode before
executing the rest of the function. This allows these functions to
be called from non-interworking code.
-mcaller-super-interworking
Allows calls via function pointers (including virtual functions) to
execute correctly regardless of whether the target code has been
compiled for interworking or not. There is a small overhead in the
cost of executing a function pointer if this option is enabled.
-mtp=name
Specify the access model for the thread local storage pointer. The
valid models are soft, which generates calls to "__aeabi_read_tp",
cp15, which fetches the thread pointer from "cp15" directly
(supported in the arm6k architecture), and auto, which uses the
best available method for the selected processor. The default
setting is auto.
-mword-relocations
Only generate absolute relocations on word sized values (i.e.
R_ARM_ABS32). This is enabled by default on targets (uClinux,
SymbianOS) where the runtime loader imposes this restriction, and
when -fpic or -fPIC is specified.
AVR Options
These options are defined for AVR implementations:
-mmcu=mcu
Specify ATMEL AVR instruction set or MCU type.
Instruction set avr1 is for the minimal AVR core, not supported by
the C compiler, only for assembler programs (MCU types: at90s1200,
attiny10, attiny11, attiny12, attiny15, attiny28).
Instruction set avr2 (default) is for the classic AVR core with up
to 8K program memory space (MCU types: at90s2313, at90s2323,
attiny22, at90s2333, at90s2343, at90s4414, at90s4433, at90s4434,
at90s8515, at90c8534, at90s8535).
Instruction set avr3 is for the classic AVR core with up to 128K
program memory space (MCU types: atmega103, atmega603, at43usb320,
at76c711).
Instruction set avr4 is for the enhanced AVR core with up to 8K
program memory space (MCU types: atmega8, atmega83, atmega85).
Instruction set avr5 is for the enhanced AVR core with up to 128K
program memory space (MCU types: atmega16, atmega161, atmega163,
atmega32, atmega323, atmega64, atmega128, at43usb355, at94k).
-msize
Output instruction sizes to the asm file.
-mno-interrupts
Generated code is not compatible with hardware interrupts. Code
size will be smaller.
-mcall-prologues
Functions prologues/epilogues expanded as call to appropriate
subroutines. Code size will be smaller.
-mno-tablejump
Do not generate tablejump insns which sometimes increase code size.
The option is now deprecated in favor of the equivalent
-fno-jump-tables
-mtiny-stack
Change only the low 8 bits of the stack pointer.
-mint8
Assume int to be 8 bit integer. This affects the sizes of all
types: A char will be 1 byte, an int will be 1 byte, an long will
be 2 bytes and long long will be 4 bytes. Please note that this
option does not comply to the C standards, but it will provide you
with smaller code size.
Blackfin Options
-mcpu=cpu[-sirevision]
Specifies the name of the target Blackfin processor. Currently,
cpu can be one of bf512, bf514, bf516, bf518, bf522, bf523, bf524,
bf525, bf526, bf527, bf531, bf532, bf533, bf534, bf536, bf537,
bf538, bf539, bf542, bf544, bf547, bf548, bf549, bf561. The
optional sirevision specifies the silicon revision of the target
Blackfin processor. Any workarounds available for the targeted
silicon revision will be enabled. If sirevision is none, no
workarounds are enabled. If sirevision is any, all workarounds for
the targeted processor will be enabled. The "__SILICON_REVISION__"
macro is defined to two hexadecimal digits representing the major
and minor numbers in the silicon revision. If sirevision is none,
the "__SILICON_REVISION__" is not defined. If sirevision is any,
the "__SILICON_REVISION__" is defined to be 0xffff. If this
optional sirevision is not used, GCC assumes the latest known
silicon revision of the targeted Blackfin processor.
Support for bf561 is incomplete. For bf561, Only the processor
macro is defined. Without this option, bf532 is used as the
processor by default. The corresponding predefined processor
macros for cpu is to be defined. And for bfin-elf toolchain, this
causes the hardware BSP provided by libgloss to be linked in if
-msim is not given.
-msim
Specifies that the program will be run on the simulator. This
causes the simulator BSP provided by libgloss to be linked in.
This option has effect only for bfin-elf toolchain. Certain other
options, such as -mid-shared-library and -mfdpic, imply -msim.
-momit-leaf-frame-pointer
Don't keep the frame pointer in a register for leaf functions.
This avoids the instructions to save, set up and restore frame
pointers and makes an extra register available in leaf functions.
The option -fomit-frame-pointer removes the frame pointer for all
functions which might make debugging harder.
-mspecld-anomaly
When enabled, the compiler will ensure that the generated code does
not contain speculative loads after jump instructions. If this
option is used, "__WORKAROUND_SPECULATIVE_LOADS" is defined.
-mno-specld-anomaly
Don't generate extra code to prevent speculative loads from
occurring.
-mcsync-anomaly
When enabled, the compiler will ensure that the generated code does
not contain CSYNC or SSYNC instructions too soon after conditional
branches. If this option is used, "__WORKAROUND_SPECULATIVE_SYNCS"
is defined.
-mno-csync-anomaly
Don't generate extra code to prevent CSYNC or SSYNC instructions
from occurring too soon after a conditional branch.
-mlow-64k
When enabled, the compiler is free to take advantage of the
knowledge that the entire program fits into the low 64k of memory.
-mno-low-64k
Assume that the program is arbitrarily large. This is the default.
-mstack-check-l1
Do stack checking using information placed into L1 scratchpad
memory by the uClinux kernel.
-mid-shared-library
Generate code that supports shared libraries via the library ID
method. This allows for execute in place and shared libraries in
an environment without virtual memory management. This option
implies -fPIC. With a bfin-elf target, this option implies -msim.
-mno-id-shared-library
Generate code that doesn't assume ID based shared libraries are
being used. This is the default.
-mleaf-id-shared-library
Generate code that supports shared libraries via the library ID
method, but assumes that this library or executable won't link
against any other ID shared libraries. That allows the compiler to
use faster code for jumps and calls.
-mno-leaf-id-shared-library
Do not assume that the code being compiled won't link against any
ID shared libraries. Slower code will be generated for jump and
call insns.
-mshared-library-id=n
Specified the identification number of the ID based shared library
being compiled. Specifying a value of 0 will generate more compact
code, specifying other values will force the allocation of that
number to the current library but is no more space or time
efficient than omitting this option.
-msep-data
Generate code that allows the data segment to be located in a
different area of memory from the text segment. This allows for
execute in place in an environment without virtual memory
management by eliminating relocations against the text section.
-mno-sep-data
Generate code that assumes that the data segment follows the text
segment. This is the default.
-mlong-calls
-mno-long-calls
Tells the compiler to perform function calls by first loading the
address of the function into a register and then performing a
subroutine call on this register. This switch is needed if the
target function will lie outside of the 24 bit addressing range of
the offset based version of subroutine call instruction.
This feature is not enabled by default. Specifying -mno-long-calls
will restore the default behavior. Note these switches have no
effect on how the compiler generates code to handle function calls
via function pointers.
-mfast-fp
Link with the fast floating-point library. This library relaxes
some of the IEEE floating-point standard's rules for checking
inputs against Not-a-Number (NAN), in the interest of performance.
-minline-plt
Enable inlining of PLT entries in function calls to functions that
are not known to bind locally. It has no effect without -mfdpic.
-mmulticore
Build standalone application for multicore Blackfin processor.
Proper start files and link scripts will be used to support
multicore. This option defines "__BFIN_MULTICORE". It can only be
used with -mcpu=bf561[-sirevision]. It can be used with -mcorea or
-mcoreb. If it's used without -mcorea or -mcoreb, single
application/dual core programming model is used. In this model, the
main function of Core B should be named as coreb_main. If it's used
with -mcorea or -mcoreb, one application per core programming model
is used. If this option is not used, single core application
programming model is used.
-mcorea
Build standalone application for Core A of BF561 when using one
application per core programming model. Proper start files and link
scripts will be used to support Core A. This option defines
"__BFIN_COREA". It must be used with -mmulticore.
-mcoreb
Build standalone application for Core B of BF561 when using one
application per core programming model. Proper start files and link
scripts will be used to support Core B. This option defines
"__BFIN_COREB". When this option is used, coreb_main should be used
instead of main. It must be used with -mmulticore.
-msdram
Build standalone application for SDRAM. Proper start files and link
scripts will be used to put the application into SDRAM. Loader
should initialize SDRAM before loading the application into SDRAM.
This option defines "__BFIN_SDRAM".
-micplb
Assume that ICPLBs are enabled at runtime. This has an effect on
certain anomaly workarounds. For Linux targets, the default is to
assume ICPLBs are enabled; for standalone applications the default
is off.
CRIS Options
These options are defined specifically for the CRIS ports.
-march=architecture-type
-mcpu=architecture-type
Generate code for the specified architecture. The choices for
architecture-type are v3, v8 and v10 for respectively ETRAX 4,
ETRAX 100, and ETRAX 100 LX. Default is v0 except for cris-axis-
linux-gnu, where the default is v10.
-mtune=architecture-type
Tune to architecture-type everything applicable about the generated
code, except for the ABI and the set of available instructions.
The choices for architecture-type are the same as for
-march=architecture-type.
-mmax-stack-frame=n
Warn when the stack frame of a function exceeds n bytes.
-metrax4
-metrax100
The options -metrax4 and -metrax100 are synonyms for -march=v3 and
-march=v8 respectively.
-mmul-bug-workaround
-mno-mul-bug-workaround
Work around a bug in the "muls" and "mulu" instructions for CPU
models where it applies. This option is active by default.
-mpdebug
Enable CRIS-specific verbose debug-related information in the
assembly code. This option also has the effect to turn off the
#NO_APP formatted-code indicator to the assembler at the beginning
of the assembly file.
-mcc-init
Do not use condition-code results from previous instruction; always
emit compare and test instructions before use of condition codes.
-mno-side-effects
Do not emit instructions with side-effects in addressing modes
other than post-increment.
-mstack-align
-mno-stack-align
-mdata-align
-mno-data-align
-mconst-align
-mno-const-align
These options (no-options) arranges (eliminate arrangements) for
the stack-frame, individual data and constants to be aligned for
the maximum single data access size for the chosen CPU model. The
default is to arrange for 32-bit alignment. ABI details such as
structure layout are not affected by these options.
-m32-bit
-m16-bit
-m8-bit
Similar to the stack- data- and const-align options above, these
options arrange for stack-frame, writable data and constants to all
be 32-bit, 16-bit or 8-bit aligned. The default is 32-bit
alignment.
-mno-prologue-epilogue
-mprologue-epilogue
With -mno-prologue-epilogue, the normal function prologue and
epilogue that sets up the stack-frame are omitted and no return
instructions or return sequences are generated in the code. Use
this option only together with visual inspection of the compiled
code: no warnings or errors are generated when call-saved registers
must be saved, or storage for local variable needs to be allocated.
-mno-gotplt
-mgotplt
With -fpic and -fPIC, don't generate (do generate) instruction
sequences that load addresses for functions from the PLT part of
the GOT rather than (traditional on other architectures) calls to
the PLT. The default is -mgotplt.
-melf
Legacy no-op option only recognized with the cris-axis-elf and
cris-axis-linux-gnu targets.
-mlinux
Legacy no-op option only recognized with the cris-axis-linux-gnu
target.
-sim
This option, recognized for the cris-axis-elf arranges to link with
input-output functions from a simulator library. Code, initialized
data and zero-initialized data are allocated consecutively.
-sim2
Like -sim, but pass linker options to locate initialized data at
0x40000000 and zero-initialized data at 0x80000000.
CRX Options
These options are defined specifically for the CRX ports.
-mmac
Enable the use of multiply-accumulate instructions. Disabled by
default.
-mpush-args
Push instructions will be used to pass outgoing arguments when
functions are called. Enabled by default.
Darwin Options
These options are defined for all architectures running the Darwin
operating system.
FSF GCC on Darwin does not create "fat" object files; it will create an
object file for the single architecture that it was built to target.
Apple's GCC on Darwin does create "fat" files if multiple -arch options
are used; it does so by running the compiler or linker multiple times
and joining the results together with lipo.
The subtype of the file created (like ppc7400 or ppc970 or i686) is
determined by the flags that specify the ISA that GCC is targetting,
like -mcpu or -march. The -force_cpusubtype_ALL option can be used to
override this.
The Darwin tools vary in their behavior when presented with an ISA
mismatch. The assembler, as, will only permit instructions to be used
that are valid for the subtype of the file it is generating, so you
cannot put 64-bit instructions in an ppc750 object file. The linker
for shared libraries, /usr/bin/libtool, will fail and print an error if
asked to create a shared library with a less restrictive subtype than
its input files (for instance, trying to put a ppc970 object file in a
ppc7400 library). The linker for executables, ld, will quietly give
the executable the most restrictive subtype of any of its input files.
-Fdir
Add the framework directory dir to the head of the list of
directories to be searched for header files. These directories are
interleaved with those specified by -I options and are scanned in a
left-to-right order.
A framework directory is a directory with frameworks in it. A
framework is a directory with a "Headers" and/or "PrivateHeaders"
directory contained directly in it that ends in ".framework". The
name of a framework is the name of this directory excluding the
".framework". Headers associated with the framework are found in
one of those two directories, with "Headers" being searched first.
A subframework is a framework directory that is in a framework's
"Frameworks" directory. Includes of subframework headers can only
appear in a header of a framework that contains the subframework,
or in a sibling subframework header. Two subframeworks are
siblings if they occur in the same framework. A subframework
should not have the same name as a framework, a warning will be
issued if this is violated. Currently a subframework cannot have
subframeworks, in the future, the mechanism may be extended to
support this. The standard frameworks can be found in
"/System/Library/Frameworks" and "/Library/Frameworks". An example
include looks like "#include", where Framework
denotes the name of the framework and header.h is found in the
"PrivateHeaders" or "Headers" directory.
-iframeworkdir
Like -F except the directory is a treated as a system directory.
The main difference between this -iframework and -F is that with
-iframework the compiler does not warn about constructs contained
within header files found via dir. This option is valid only for
the C family of languages.
-gused
Emit debugging information for symbols that are used. For STABS
debugging format, this enables -feliminate-unused-debug-symbols.
This is by default ON.
-gfull
Emit debugging information for all symbols and types.
-mmacosx-version-min=version
The earliest version of MacOS X that this executable will run on is
version. Typical values of version include 10.1, 10.2, and 10.3.9.
If the compiler was built to use the system's headers by default,
then the default for this option is the system version on which the
compiler is running, otherwise the default is to make choices which
are compatible with as many systems and code bases as possible.
-mkernel
Enable kernel development mode. The -mkernel option sets -static,
-fno-common, -fno-cxa-atexit, -fno-exceptions,
-fno-non-call-exceptions, -fapple-kext, -fno-weak and -fno-rtti
where applicable. This mode also sets -mno-altivec, -msoft-float,
-fno-builtin and -mlong-branch for PowerPC targets.
-mone-byte-bool
Override the defaults for bool so that sizeof(bool)==1. By default
sizeof(bool) is 4 when compiling for Darwin/PowerPC and 1 when
compiling for Darwin/x86, so this option has no effect on x86.
Warning: The -mone-byte-bool switch causes GCC to generate code
that is not binary compatible with code generated without that
switch. Using this switch may require recompiling all other
modules in a program, including system libraries. Use this switch
to conform to a non-default data model.
-mfix-and-continue
-ffix-and-continue
-findirect-data
Generate code suitable for fast turn around development. Needed to
enable gdb to dynamically load ".o" files into already running
programs. -findirect-data and -ffix-and-continue are provided for
backwards compatibility.
-all_load
Loads all members of static archive libraries. See man ld(1) for
more information.
-arch_errors_fatal
Cause the errors having to do with files that have the wrong
architecture to be fatal.
-bind_at_load
Causes the output file to be marked such that the dynamic linker
will bind all undefined references when the file is loaded or
launched.
-bundle
Produce a Mach-o bundle format file. See man ld(1) for more
information.
-bundle_loader executable
This option specifies the executable that will be loading the build
output file being linked. See man ld(1) for more information.
-dynamiclib
When passed this option, GCC will produce a dynamic library instead
of an executable when linking, using the Darwin libtool command.
-force_cpusubtype_ALL
This causes GCC's output file to have the ALL subtype, instead of
one controlled by the -mcpu or -march option.
-allowable_client client_name
-client_name
-compatibility_version
-current_version
-dead_strip
-dependency-file
-dylib_file
-dylinker_install_name
-dynamic
-exported_symbols_list
-filelist
-flat_namespace
-force_flat_namespace
-headerpad_max_install_names
-image_base
-init
-install_name
-keep_private_externs
-multi_module
-multiply_defined
-multiply_defined_unused
-noall_load
-no_dead_strip_inits_and_terms
-nofixprebinding
-nomultidefs
-noprebind
-noseglinkedit
-pagezero_size
-prebind
-prebind_all_twolevel_modules
-private_bundle
-read_only_relocs
-sectalign
-sectobjectsymbols
-whyload
-seg1addr
-sectcreate
-sectobjectsymbols
-sectorder
-segaddr
-segs_read_only_addr
-segs_read_write_addr
-seg_addr_table
-seg_addr_table_filename
-seglinkedit
-segprot
-segs_read_only_addr
-segs_read_write_addr
-single_module
-static
-sub_library
-sub_umbrella
-twolevel_namespace
-umbrella
-undefined
-unexported_symbols_list
-weak_reference_mismatches
-whatsloaded
These options are passed to the Darwin linker. The Darwin linker
man page describes them in detail.
Saturday, December 11, 2010
gcc (page 6)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment