AVR Libc Home Page | AVR Libc Development Pages | ||||
Main Page | User Manual | Library Reference | FAQ | Alphabetical Index | Example Projects |
The following describes the various sections available.
The .text section contains the actual machine instructions which make up your program. This section is further subdivided by the .initN and .finiN sections dicussed below.
avr-size
program (part of binutils), coming from a Unix background, doesn't account for the .data initialization space added to the .text section, so in order to know how much flash the final program will consume, one needs to add the values for both, .text and .data (but not .bss), while the amount of pre-allocated SRAM is the sum of .data and .bss.This section contains static data which was defined in your code. Things like the following would end up in .data:
char err_str[] = "Your program has died a horrible death!"; struct point pt = { 1, 1 };
It is possible to tell the linker the SRAM address of the beginning of the .data section. This is accomplished by adding -Wl,-Tdata,addr
to the avr-gcc
command used to the link your program. Not that addr
must be offset by adding 0x800000 the to real SRAM address so that the linker knows that the address is in the SRAM memory space. Thus, if you want the .data section to start at 0x1100, pass 0x801100 at the address to the linker. [offset explained]
malloc()
in the application (which could even happen inside library calls), additional adjustments are required.Uninitialized global or static variables end up in the .bss section.
This is where eeprom variables are stored.
This sections is a part of the .bss section. What makes the .noinit section special is that variables which are defined as such:
int foo __attribute__ ((section (".noinit")));
will not be initialized to zero during startup as would normal .bss data.
Only uninitialized variables can be placed in the .noinit section. Thus, the following code will cause avr-gcc
to issue an error:
int bar __attribute__ ((section (".noinit"))) = 0xaa;
It is possible to tell the linker explicitly where to place the .noinit section by adding -Wl,--section-start=.noinit=0x802000
to the avr-gcc
command line at the linking stage. For example, suppose you wish to place the .noinit section at SRAM address 0x2000:
$ avr-gcc ... -Wl,--section-start=.noinit=0x802000 ...
Alternatively, you can write your own linker script to automate this. [FIXME: need an example or ref to dox for writing linker scripts.]
These sections are used to define the startup code from reset up through the start of main(). These all are subparts of the .text section.
The purpose of these sections is to allow for more specific placement of code within your program.
The .initN sections are executed in order from 0 to 9.
For devices with > 64 KB of ROM, .init4 defines the code which takes care of copying the contents of .data from the flash to SRAM. For all other devices, this code as well as the code to zero out the .bss section is loaded from libgcc.a.
These sections are used to define the exit code executed after return from main() or a call to exit(). These all are subparts of the .text section.
The .finiN sections are executed in descending order from 9 to 0.
Example:
#include <avr/io.h> .section .init1,"ax",@progbits ldi r0, 0xff out _SFR_IO_ADDR(PORTB), r0 out _SFR_IO_ADDR(DDRB), r0
,"ax",@progbits
tells the assembler that the section is allocatable ("a"), executable ("x") and contains data ("@progbits"). For more detailed information on the .section directive, see the gas user manual.Example:
#include <avr/io.h> void my_init_portb (void) __attribute__ ((naked)) \ __attribute__ ((section (".init3"))); void my_init_portb (void) { PORTB = 0xff; DDRB = 0xff; }
__zero_reg__
has already been set up. The code generated by the compiler might blindly rely on __zero_reg__
being really 0.