Using the GNU tools This is a short summary of the AVR-specific aspects of using the GNU tools. Normally, the generic documentation of these tools is fairly large and maintained in texinfo files …
The following machine-specific options are recognized by the C compiler frontend. In addition to the preprocessor macros indicated in the tables below, the preprocessor will define the macros __AVR and __AVR__ (to the value 1) when compiling for an AVR target. The macro AVR will be defined as well when using the standard levels gnu89 (default) and gnu99 but not with c89 and c99.
Compile code for architecture. Currently known architectures are
Architecture Macros Description avr1 __AVR_ARCH__=1
__AVR_ASM_ONLY__
__AVR_2_BYTE_PC__ [2] Simple CPU core, only assembler support avr2
__AVR_ARCH__=2
__AVR_2_BYTE_PC__ [2] 'Classic' CPU core, up to 8 KB of ROM avr25 [1]
__AVR_ARCH__=25
__AVR_HAVE_MOVW__ [1]
__AVR_HAVE_LPMX__ [1]
__AVR_2_BYTE_PC__ [2] 'Classic' CPU core with 'MOVW' and 'LPM Rx, Z[+]'
instruction, up to 8 KB of ROM avr3 __AVR_ARCH__=3
__AVR_MEGA__ [5]
__AVR_HAVE_JMP_CALL__ [4]
__AVR_2_BYTE_PC__ [2] 'Classic' CPU core, 16 KB to 64 KB of ROM avr31
__AVR_ARCH__=31
__AVR_MEGA__ [5]
__AVR_HAVE_JMP_CALL__ [4]
__AVR_HAVE_RAMPZ__ [4]
__AVR_HAVE_ELPM__ [4]
__AVR_2_BYTE_PC__ [2] 'Classic' CPU core, 128 KB of ROM avr35 [3]
__AVR_ARCH__=35
__AVR_MEGA__ [5]
__AVR_HAVE_JMP_CALL__ [4]
__AVR_HAVE_MOVW__ [1]
__AVR_HAVE_LPMX__ [1]
__AVR_2_BYTE_PC__ [2] 'Classic' CPU core with 'MOVW' and 'LPM Rx, Z[+]'
instruction, 16 KB to 64 KB of ROM avr4 __AVR_ARCH__=4
__AVR_ENHANCED__ [5]
__AVR_HAVE_MOVW__ [1]
__AVR_HAVE_LPMX__ [1]
__AVR_HAVE_MUL__ [1]
__AVR_2_BYTE_PC__ [2] 'Enhanced' CPU core, up to 8 KB of ROM avr5
__AVR_ARCH__=5
__AVR_MEGA__ [5]
__AVR_ENHANCED__ [5]
__AVR_HAVE_JMP_CALL__ [4]
__AVR_HAVE_MOVW__ [1]
__AVR_HAVE_LPMX__ [1]
__AVR_HAVE_MUL__ [1]
__AVR_2_BYTE_PC__ [2] 'Enhanced' CPU core, 16 KB to 64 KB of ROM avr51
__AVR_ARCH__=51
__AVR_MEGA__ [5]
__AVR_ENHANCED__ [5]
__AVR_HAVE_JMP_CALL__ [4]
__AVR_HAVE_MOVW__ [1]
__AVR_HAVE_LPMX__ [1]
__AVR_HAVE_MUL__ [1]
__AVR_HAVE_RAMPZ__ [4]
__AVR_HAVE_ELPM__ [4]
__AVR_HAVE_ELPMX__ [4]
__AVR_2_BYTE_PC__ [2] 'Enhanced' CPU core, 128 KB of ROM avr6 [2]
__AVR_ARCH__=6
__AVR_MEGA__ [5]
__AVR_ENHANCED__ [5]
__AVR_HAVE_JMP_CALL__ [4]
__AVR_HAVE_MOVW__ [1]
__AVR_HAVE_LPMX__ [1]
__AVR_HAVE_MUL__ [1]
__AVR_HAVE_RAMPZ__ [4]
__AVR_HAVE_ELPM__ [4]
__AVR_HAVE_ELPMX__ [4]
__AVR_3_BYTE_PC__ [2] 'Enhanced' CPU core, 256 KB of ROM
[1] New in GCC 4.2
[2] Unofficial patch for GCC 4.1
[3] New in GCC 4.2.3
[4] New in GCC 4.3
[5] Obsolete.
By default, code is generated for the avr2 architecture.
Note that when only using -mmcu=architecture but no -mmcu=MCU type, including the file <avr/io.h> cannot work since it cannot decide which device's definitions to select.
The following MCU types are currently understood by avr-gcc. The table matches them against the corresponding avr-gcc architecture name, and shows the preprocessor symbol declared by the -mmcu option.
ArchitectureMCU nameMacro
avr1at90s1200__AVR_AT90S1200__ avr1attiny11__AVR_ATtiny11__ avr1attiny12__AVR_ATtiny12__ avr1attiny15__AVR_ATtiny15__ avr1attiny28__AVR_ATtiny28__
avr2at90s2313__AVR_AT90S2313__ avr2at90s2323__AVR_AT90S2323__ avr2at90s2333__AVR_AT90S2333__ avr2at90s2343__AVR_AT90S2343__ avr2attiny22__AVR_ATtiny22__ avr2attiny26__AVR_ATtiny26__ avr2at90s4414__AVR_AT90S4414__ avr2at90s4433__AVR_AT90S4433__ avr2at90s4434__AVR_AT90S4434__ avr2at90s8515__AVR_AT90S8515__ avr2at90c8534__AVR_AT90C8534__ avr2at90s8535__AVR_AT90S8535__
avr2/avr25 [1]at86rf401__AVR_AT86RF401__ avr2/avr25 [1]ata5272__AVR_ATA5272__ avr2/avr25 [1]ata6616c__AVR_ATA6616C__ avr2/avr25 [1]attiny13__AVR_ATtiny13__ avr2/avr25 [1]attiny13a__AVR_ATtiny13A__ avr2/avr25 [1]attiny2313__AVR_ATtiny2313__ avr2/avr25 [1]attiny2313a__AVR_ATtiny2313A__ avr2/avr25 [1]attiny24__AVR_ATtiny24__ avr2/avr25 [1]attiny24a__AVR_ATtiny24A__ avr2/avr25 [1]attiny25__AVR_ATtiny25__ avr2/avr25 [1]attiny261__AVR_ATtiny261__ avr2/avr25 [1]attiny261a__AVR_ATtiny261A__ avr2/avr25 [1]attiny4313__AVR_ATtiny4313__ avr2/avr25 [1]attiny43u__AVR_ATtiny43U__ avr2/avr25 [1]attiny44__AVR_ATtiny44__ avr2/avr25 [1]attiny44a__AVR_ATtiny44A__ avr2/avr25 [1]attiny441__AVR_ATtiny441__ avr2/avr25 [1]attiny45__AVR_ATtiny45__ avr2/avr25 [1]attiny461__AVR_ATtiny461__ avr2/avr25 [1]attiny461a__AVR_ATtiny461A__ avr2/avr25 [1]attiny48__AVR_ATtiny48__ avr2/avr25 [1]attiny828__AVR_ATtiny828__ avr2/avr25 [1]attiny84__AVR_ATtiny84__ avr2/avr25 [1]attiny84a__AVR_ATtiny84A__ avr2/avr25 [1]attiny841__AVR_ATtiny841__ avr2/avr25 [1]attiny85__AVR_ATtiny85__ avr2/avr25 [1]attiny861__AVR_ATtiny861__ avr2/avr25 [1]attiny861a__AVR_ATtiny861A__ avr2/avr25 [1]attiny87__AVR_ATtiny87__ avr2/avr25 [1]attiny88__AVR_ATtiny88__
avr3atmega603__AVR_ATmega603__ avr3at43usb355__AVR_AT43USB355__
avr3/avr31 [3]atmega103__AVR_ATmega103__ avr3/avr31 [3]at43usb320__AVR_AT43USB320__
avr3/avr35 [2]at90usb82__AVR_AT90USB82__ avr3/avr35 [2]at90usb162__AVR_AT90USB162__ avr3/avr35 [2]ata5505__AVR_ATA5505__ avr3/avr35 [2]ata6617c__AVR_ATA6617C__ avr3/avr35 [2]ata664251__AVR_ATA664251__ avr3/avr35 [2]atmega8u2__AVR_ATmega8U2__ avr3/avr35 [2]atmega16u2__AVR_ATmega16U2__ avr3/avr35 [2]atmega32u2__AVR_ATmega32U2__ avr3/avr35 [2]attiny167__AVR_ATtiny167__ avr3/avr35 [2]attiny1634__AVR_ATtiny1634__
avr3at76c711__AVR_AT76C711__ avr4ata6285__AVR_ATA6285__ avr4ata6286__AVR_ATA6286__ avr4ata6289__AVR_ATA6289__ avr4ata6612c__AVR_ATA6612C__ avr4atmega48__AVR_ATmega48__ avr4atmega48a__AVR_ATmega48A__ avr4atmega48pa__AVR_ATmega48PA__ avr4atmega48pb__AVR_ATmega48PB__ avr4atmega48p__AVR_ATmega48P__ avr4atmega8__AVR_ATmega8__ avr4atmega8a__AVR_ATmega8A__ avr4atmega8515__AVR_ATmega8515__ avr4atmega8535__AVR_ATmega8535__ avr4atmega88__AVR_ATmega88__ avr4atmega88a__AVR_ATmega88A__ avr4atmega88p__AVR_ATmega88P__ avr4atmega88pa__AVR_ATmega88PA__ avr4atmega88pb__AVR_ATmega88PB__ avr4atmega8hva__AVR_ATmega8HVA__ avr4at90pwm1__AVR_AT90PWM1__ avr4at90pwm2__AVR_AT90PWM2__ avr4at90pwm2b__AVR_AT90PWM2B__ avr4at90pwm3__AVR_AT90PWM3__ avr4at90pwm3b__AVR_AT90PWM3B__ avr4at90pwm81__AVR_AT90PWM81__
avr5at90can32__AVR_AT90CAN32__ avr5at90can64__AVR_AT90CAN64__ avr5at90pwm161__AVR_AT90PWM161__ avr5at90pwm216__AVR_AT90PWM216__ avr5at90pwm316__AVR_AT90PWM316__ avr5at90scr100__AVR_AT90SCR100__ avr5at90usb646__AVR_AT90USB646__ avr5at90usb647__AVR_AT90USB647__ avr5at94k__AVR_AT94K__ avr5atmega16__AVR_ATmega16__ avr5ata5702m322__AVR_ATA5702M322__ avr5ata5782__AVR_ATA5782__ avr5ata5790__AVR_ATA5790__ avr5ata5790n__AVR_ATA5790N__ avr5ata5791__AVR_ATA5791__ avr5ata5795__AVR_ATA5795__ avr5ata5831__AVR_ATA5831__ avr5ata6613c__AVR_ATA6613C__ avr5ata6614q__AVR_ATA6614Q__ avr5ata8210__AVR_ATA8210__ avr5ata8510__AVR_ATA8510__ avr5atmega161__AVR_ATmega161__ avr5atmega162__AVR_ATmega162__ avr5atmega163__AVR_ATmega163__ avr5atmega164a__AVR_ATmega164A__ avr5atmega164p__AVR_ATmega164P__ avr5atmega164pa__AVR_ATmega164PA__ avr5atmega165__AVR_ATmega165__ avr5atmega165a__AVR_ATmega165A__ avr5atmega165p__AVR_ATmega165P__ avr5atmega165pa__AVR_ATmega165PA__ avr5atmega168__AVR_ATmega168__ avr5atmega168a__AVR_ATmega168A__ avr5atmega168p__AVR_ATmega168P__ avr5atmega168pa__AVR_ATmega168PA__ avr5atmega168pb__AVR_ATmega168PB__ avr5atmega169__AVR_ATmega169__ avr5atmega169a__AVR_ATmega169A__ avr5atmega169p__AVR_ATmega169P__ avr5atmega169pa__AVR_ATmega169PA__ avr5atmega16a__AVR_ATmega16A__ avr5atmega16hva__AVR_ATmega16HVA__ avr5atmega16hva2__AVR_ATmega16HVA2__ avr5atmega16hvb__AVR_ATmega16HVB__ avr5atmega16hvbrevb__AVR_ATmega16HVBREVB__ avr5atmega16m1__AVR_ATmega16M1__ avr5atmega16u4__AVR_ATmega16U4__ avr5atmega32__AVR_ATmega32__ avr5atmega32a__AVR_ATmega32A__ avr5atmega323__AVR_ATmega323__ avr5atmega324a__AVR_ATmega324A__ avr5atmega324p__AVR_ATmega324P__ avr5atmega324pa__AVR_ATmega324PA__ avr5atmega325__AVR_ATmega325__ avr5atmega325a__AVR_ATmega325A__ avr5atmega325p__AVR_ATmega325P__ avr5atmega325pa__AVR_ATmega325PA__ avr5atmega3250__AVR_ATmega3250__ avr5atmega3250a__AVR_ATmega3250A__ avr5atmega3250p__AVR_ATmega3250P__ avr5atmega3250pa__AVR_ATmega3250PA__ avr5atmega328__AVR_ATmega328__ avr5atmega328p__AVR_ATmega328P__ avr5atmega329__AVR_ATmega329__ avr5atmega329a__AVR_ATmega329A__ avr5atmega329p__AVR_ATmega329P__ avr5atmega329pa__AVR_ATmega329PA__ avr5atmega3290__AVR_ATmega3290__ avr5atmega3290a__AVR_ATmega3290A__ avr5atmega3290p__AVR_ATmega3290P__ avr5atmega3290pa__AVR_ATmega3290PA__ avr5atmega32c1__AVR_ATmega32C1__ avr5atmega32hvb__AVR_ATmega32HVB__ avr5atmega32hvbrevb__AVR_ATmega32HVBREVB__ avr5atmega32m1__AVR_ATmega32M1__ avr5atmega32u4__AVR_ATmega32U4__ avr5atmega32u6__AVR_ATmega32U6__ avr5atmega406__AVR_ATmega406__ avr5atmega644rfr2__AVR_ATmega644RFR2__ avr5atmega64rfr2__AVR_ATmega64RFR2__ avr5atmega64__AVR_ATmega64__ avr5atmega64a__AVR_ATmega64A__ avr5atmega640__AVR_ATmega640__ avr5atmega644__AVR_ATmega644__ avr5atmega644a__AVR_ATmega644A__ avr5atmega644p__AVR_ATmega644P__ avr5atmega644pa__AVR_ATmega644PA__ avr5atmega645__AVR_ATmega645__ avr5atmega645a__AVR_ATmega645A__ avr5atmega645p__AVR_ATmega645P__ avr5atmega6450__AVR_ATmega6450__ avr5atmega6450a__AVR_ATmega6450A__ avr5atmega6450p__AVR_ATmega6450P__ avr5atmega649__AVR_ATmega649__ avr5atmega649a__AVR_ATmega649A__ avr5atmega6490__AVR_ATmega6490__ avr5atmega6490a__AVR_ATmega6490A__ avr5atmega6490p__AVR_ATmega6490P__ avr5atmega649p__AVR_ATmega649P__ avr5atmega64c1__AVR_ATmega64C1__ avr5atmega64hve__AVR_ATmega64HVE__ avr5atmega64hve2__AVR_ATmega64HVE2__ avr5atmega64m1__AVR_ATmega64M1__ avr5m3000__AVR_M3000__
avr5/avr51 [3]at90can128__AVR_AT90CAN128__ avr5/avr51 [3]at90usb1286__AVR_AT90USB1286__ avr5/avr51 [3]at90usb1287__AVR_AT90USB1287__ avr5/avr51 [3]atmega128__AVR_ATmega128__ avr5/avr51 [3]atmega128a__AVR_ATmega128A__ avr5/avr51 [3]atmega1280__AVR_ATmega1280__ avr5/avr51 [3]atmega1281__AVR_ATmega1281__ avr5/avr51 [3]atmega1284__AVR_ATmega1284__ avr5/avr51 [3]atmega1284p__AVR_ATmega1284P__ avr5/avr51 [3]atmega1284rfr2__AVR_ATmega1284RFR2__ avr5/avr51 [3]atmega128rfr2__AVR_ATmega128RFR2__
avr6atmega2560__AVR_ATmega2560__ avr6atmega2561__AVR_ATmega2561__ avr6atmega2564rfr2__AVR_ATmega2564RFR2__ avr6atmega256rfr2__AVR_ATmega256RFR2__
avrxmega2atxmega8e5__AVR_ATxmega8E5__ avrxmega2atxmega16a4__AVR_ATxmega16A4__ avrxmega2atxmega16a4u__AVR_ATxmega16A4U__ avrxmega2atxmega16c4__AVR_ATxmega16C4__ avrxmega2atxmega16d4__AVR_ATxmega16D4__ avrxmega2atxmega16e5__AVR_ATxmega16E5__ avrxmega2atxmega32a4__AVR_ATxmega32A4__ avrxmega2atxmega32a4u__AVR_ATxmega32A4U__ avrxmega2atxmega32c3__AVR_ATxmega32C3__ avrxmega2atxmega32c4__AVR_ATxmega32C4__ avrxmega2atxmega32d3__AVR_ATxmega32D3__ avrxmega2atxmega32d4__AVR_ATxmega32D4__ avrxmega2atxmega32e5__AVR_ATxmega32E5__
avrxmega4atxmega64a3__AVR_ATxmega64A3__ avrxmega4atxmega64a3u__AVR_ATxmega64A3U__ avrxmega4atxmega64a4u__AVR_ATxmega64A4U__ avrxmega4atxmega64b1__AVR_ATxmega64B1__ avrxmega4atxmega64b3__AVR_ATxmega64B3__ avrxmega4atxmega64c3__AVR_ATxmega64C3__ avrxmega4atxmega64d3__AVR_ATxmega64D3__ avrxmega4atxmega64d4__AVR_ATxmega64D4__
avrxmega5atxmega64a1__AVR_ATxmega64A1__ avrxmega5atxmega64a1u__AVR_ATxmega64A1U__
avrxmega6atxmega128a3__AVR_ATxmega128A3__ avrxmega6atxmega128a3u__AVR_ATxmega128A3U__ avrxmega6atxmega128b1__AVR_ATxmega128B1__ avrxmega6atxmega128b3__AVR_ATxmega128B3__ avrxmega6atxmega128c3__AVR_ATxmega128C3__ avrxmega6atxmega128d3__AVR_ATxmega128D3__ avrxmega6atxmega128d4__AVR_ATxmega128D4__ avrxmega6atxmega192a3__AVR_ATxmega192A3__ avrxmega6atxmega192a3u__AVR_ATxmega192A3U__ avrxmega6atxmega192c3__AVR_ATxmega192C3__ avrxmega6atxmega192d3__AVR_ATxmega192D3__ avrxmega6atxmega256a3__AVR_ATxmega256A3__ avrxmega6atxmega256a3u__AVR_ATxmega256A3U__ avrxmega6atxmega256a3b__AVR_ATxmega256A3B__ avrxmega6atxmega256a3bu__AVR_ATxmega256A3BU__ avrxmega6atxmega256c3__AVR_ATxmega256C3__ avrxmega6atxmega256d3__AVR_ATxmega256D3__ avrxmega6atxmega384c3__AVR_ATxmega384C3__ avrxmega6atxmega384d3__AVR_ATxmega384D3__
avrxmega7atxmega128a1__AVR_ATxmega128A1__ avrxmega7atxmega128a1u__AVR_ATxmega128A1U__ avrxmega7atxmega128a4u__AVR_ATxmega128A4U__
avrtiny10attiny4__AVR_ATtiny4__ avrtiny10attiny5__AVR_ATtiny5__ avrtiny10attiny9__AVR_ATtiny9__ avrtiny10attiny10__AVR_ATtiny10__ avrtiny10attiny20__AVR_ATtiny20__ avrtiny10attiny40__AVR_ATtiny40__
[1] 'avr25' architecture is new in GCC 4.2
[2] 'avr35' architecture is new in GCC 4.2.3
[3] 'avr31' and 'avr51' architectures is new in GCC 4.3
Change the order of register assignment. The default is
r24, r25, r18, r19, r20, r21, r22, r23, r30, r31, r26, r27, r28, r29, r17, r16, r15, r14, r13, r12, r11, r10, r9, r8, r7, r6, r5, r4, r3, r2, r0, r1
Order 1 uses
r18, r19, r20, r21, r22, r23, r24, r25, r30, r31, r26, r27, r28, r29, r17, r16, r15, r14, r13, r12, r11, r10, r9, r8, r7, r6, r5, r4, r3, r2, r0, r1
Order 2 uses
r25, r24, r23, r22, r21, r20, r19, r18, r30, r31, r26, r27, r28, r29, r17, r16, r15, r14, r13, r12, r11, r10, r9, r8, r7, r6, r5, r4, r3, r2, r1, r0
Assume int to be an 8-bit integer. Note that this is not really supported by avr-libc, so it should normally not be used. The default is to use 16-bit integers.
Generates code that changes the stack pointer without disabling interrupts. Normally, the state of the status register SREG is saved in a temporary register, interrupts are disabled while changing the stack pointer, and SREG is restored.
Specifying this option will define the preprocessor macro __NO_INTERRUPTS__ to the value 1.
Use subroutines for function prologue/epilogue. For complex functions that use many registers (that needs to be saved/restored on function entry/exit), this saves some space at the cost of a slightly increased execution time.
Change only the low 8 bits of the stack pointer.
Deprecated, use -fno-jump-tables instead.
Use rjmp/rcall (limited range) on >8K devices. On avr2 and avr4 architectures (less than 8 KB or flash memory), this is always the case. On avr3 and avr5 architectures, calls and jumps to targets outside the current function will by default use jmp/call instructions that can cover the entire address range, but that require more flash ROM and execution time.
Dump the internal compilation result called 'RTL' into comments in the generated assembler code. Used for debugging avr-gcc.
Dump the address, size, and relative cost of each statement into comments in the generated assembler code. Used for debugging avr-gcc.
Generate lots of debugging information to stderr.
The following general gcc options might be of some interest to AVR users.
Optimization level n. Increasing n is meant to optimize more,
an optimization level of 0 means no optimization at all, which is the
default if no -O option is present. The special option -Os is meant
to turn on all -O2 optimizations that are not expected to increase code
size.
Note that at -O3, gcc attempts to inline all 'simple' functions. For the AVR target, this will normally constitute a large pessimization due to the code increasement. The only other optimization turned on with -O3 is -frename-registers, which could rather be enabled manually instead.
A simple -O option is equivalent to -O1.
Note also that turning off all optimizations will prevent some warnings from being issued since the generation of those warnings depends on code analysis steps that are only performed when optimizing (unreachable code, unused variables).
See also the appropriate FAQ entry for issues regarding debugging optimized code.
Pass the listed options to the assembler, or linker, respectively.
Generate debugging information that can be used by avr-gdb.
Assume a 'freestanding' environment as per the C standard. This turns off automatic builtin functions (though they can still be reached by prepending __builtin_ to the actual function name). It also makes the compiler not complain when main() is declared with a void return type which makes some sense in a microcontroller environment where the application cannot meaningfully provide a return value to its environment (in most cases, main() won't even return anyway). However, this also turns off all optimizations normally done by the compiler which assume that functions known by a certain name behave as described by the standard. E. g., applying the function strlen() to a literal string will normally cause the compiler to immediately replace that call by the actual length of the string, while with -ffreestanding, it will always call strlen() at run-time.
Make any unqualfied char type an unsigned char. Without this option, they default to a signed char.
Make any unqualified bitfield type unsigned. By default, they are signed.
Allocate to an enum type only as many bytes as it needs for the declared range of possible values. Specifically, the enum type will be equivalent to the smallest integer type which has enough room.
Pack all structure members together without holes.
Do not generate tablejump instructions. By default, jump tables can be used to optimize switch statements. When turned off, sequences of compare statements are used instead. Jump tables are usually faster to execute on average, but in particular for switch statements, where most of the jumps would go to the default label, they might waste a bit of flash memory.
NOTE: The tablejump instructions use the LPM assembler instruction for access to jump tables. Always use -fno-jump-tables switch, if compiling a bootloader for devices with more than 64 KB of code memory.
avr-as understands the same -mmcu= options as avr-gcc. By default, avr2 is assumed, but this can be altered by using the appropriate .arch pseudo-instruction inside the assembler source file.
Turns off opcode checking for the actual MCU type, and allows any possible AVR opcode to be assembled.
Don't emit a warning when trying to skip a 2-word instruction with a CPSE/SBIC/SBIS/SBRC/SBRS instruction. Early AVR devices suffered from a hardware bug where these instructions could not be properly skipped.
For RJMP/RCALL instructions, don't allow the target address to wrap around for devices that have more than 8 KB of memory.
Generate .stabs debugging symbols for assembler source lines. This enables avr-gdb to trace through assembler source files. This option must not be used when assembling sources that have been generated by the C compiler; these files already contain the appropriate line number information from the C source files.
Turn on the assembler listing. The sub-options are:
The various sub-options can be combined into a single -a option list; =file must be the last one in that case.
Remember that assembler options can be passed from the C compiler frontend using -Wa (see above), so in order to include the C source code into the assembler listing in file foo.lst, when compiling foo.c, the following compiler command-line can be used:
$ avr-gcc -c -O foo.c -o foo.o -Wa,-ahls=foo.lst
In order to pass an assembler file through the C preprocessor first, and have the assembler generate line number debugging information for it, the following command can be used:
$ avr-gcc -c -x assembler-with-cpp -o foo.o foo.S -Wa,--gstabs
Note that on Unix systems that have case-distinguishing file systems, specifying a file name with the suffix .S (upper-case letter S) will make the compiler automatically assume -x assembler-with-cpp, while using .s would pass the file directly to the assembler (no preprocessing done).
While there are no machine-specific options for avr-ld, a number of the standard options might be of interest to AVR users.
Locate the archive library named libname.a, and use it to resolve currently unresolved symbols from it. The library is searched along a path that consists of builtin pathname entries that have been specified at compile time (e. g. /usr/local/avr/lib on Unix systems), possibly extended by pathname entries as specified by -L options (that must precede the -l options on the command-line).
Additional location to look for archive libraries requested by -l options.
Define a global symbol symbol using expr as the value.
Print a linker map to stdout.
Print a linker map to mapfile.
Output a cross reference table to the map file (in case -Map is also present), or to stdout.
Start section sectionname at absolute address org.
Start the bss, data, or text section at org, respectively.
Use scriptfile as the linker script, replacing the default linker script. Default linker scripts are stored in a system-specific location (e. g. under /usr/local/avr/lib/ldscripts on Unix systems), and consist of the AVR architecture name (avr2 through avr5) with the suffix .x appended. They describe how the various memory sections will be linked together.
By default, all unknown non-option arguments on the avr-gcc command-line (i. e., all filename arguments that don't have a suffix that is handled by avr-gcc) are passed straight to the linker. Thus, all files ending in .o (object files) and .a (object libraries) are provided to the linker.
System libraries are usually not passed by their explicit filename but rather using the -l option which uses an abbreviated form of the archive filename (see above). avr-libc ships two system libraries, libc.a, and libm.a. While the standard library libc.a will always be searched for unresolved references when the linker is started using the C compiler frontend (i. e., there's always at least one implied -lc option), the mathematics library libm.a needs to be explicitly requested using -lm. See also the entry in the FAQ explaining this.
Conventionally, Makefiles use the make macro LDLIBS to keep track of -l (and possibly -L) options that should only be appended to the C compiler command-line when linking the final binary. In contrast, the macro LDFLAGS is used to store other command-line options to the C compiler that should be passed as options during the linking stage. The difference is that options are placed early on the command-line, while libraries are put at the end since they are to be used to resolve global symbols that are still unresolved at this point.
Specific linker flags can be passed from the C compiler command-line using the -Wl compiler option, see above. This option requires that there be no spaces in the appended linker option, while some of the linker options above (like -Map or --defsym) would require a space. In these situations, the space can be replaced by an equal sign as well. For example, the following command-line can be used to compile foo.c into an executable, and also produce a link map that contains a cross-reference list in the file foo.map:
$ avr-gcc -O -o foo.out -Wl,-Map=foo.map -Wl,--cref foo.c
Alternatively, a comma as a placeholder will be replaced by a space before passing the option to the linker. So for a device with external SRAM, the following command-line would cause the linker to place the data segment at address 0x2000 in the SRAM:
$ avr-gcc -mmcu=atmega128 -o foo.out -Wl,-Tdata,0x802000
See the explanation of the data section for why 0x800000 needs to be added to the actual value. Note that the stack will still remain in internal RAM, through the symbol __stack that is provided by the run-time startup code. This is probably a good idea anyway (since internal RAM access is faster), and even required for some early devices that had hardware bugs preventing them from using a stack in external RAM. Note also that the heap for malloc() will still be placed after all the variables in the data section, so in this situation, no stack/heap collision can occur.
In order to relocate the stack from its default location at the top of interns RAM, the value of the symbol __stack can be changed on the linker command-line. As the linker is typically called from the compiler frontend, this can be achieved using a compiler option like
-Wl,--defsym=__stack=0x8003ff
The above will make the code use stack space from RAM address 0x3ff downwards. The amount of stack space available then depends on the bottom address of internal RAM for a particular device. It is the responsibility of the application to ensure the stack does not grow out of bounds, as well as to arrange for the stack to not collide with variable allocations made by the compiler (sections .data and .bss).
