Re: [avr-gcc-list] Allocation sequence of eeprom variables

[Georg-Johann Lay]

Juergen Harms schrieb:

> I am presently switching from a rather obsolete version of avr-gcc 
> (1.6.1, downloaded as a tarball) to a much newer one (4.6.2, available 
> in an rpm package on my Mageia distribution),

avr-gcc started around 2011, with GCC version 2.95 or 3.0 or EGCS.

> [...] My question here is a problem which I have not solved yet: the old 
> version of gcc (1.6.1) allocates eeprom variables in the sequence they 
> appear in the source code to increasing addresses. The new one does the 
> allocation in the opposite order (within each object-code module): the 
> first wariable goes to the last address of the module within the .eeprom 
> section etc.

The order in which the variables are located is not specified.

> Since I use eeprom to preserve data between different executions, that 
> creates serious problems if - between two runs - I reload the executable 
> code - once generated by my old gcc, once generated by my new one, 
> eeprom variables being compiled into different locations.
>
> Any advice how to deal with this problem? Thanks!

Don't rely on unspecified behavior.  It's a bad design pattern...

The location of data is worked out by binutils (ld), not by the
compiler proper (gcc).  Thus, you can:

- Make the location explicit by writing/supplying your own linker
  script, cf. [1].  Tedious because every change in the C file needs
  an according change in the ld script.

- Layout all eeprom data as a struct.  Then it is just *one* object,
  not a zoo of objects.  You can determine the start address by, say,
  -Wl,-section-start=.eeprom=0x810001 if you use gcc as linker driver.

- Put each object in its own input section and let the linker sort the
  sections per name, see command options or ld script commands.  Use
  an order that reflects the desired location sequence.

- Use hard-coded addresses like eeprom_read_byte ((const void*) 1);
  this is not nice, not recommended and hard to maintain.

Johann


--

[1] http://sourceware.org/binutils/docs-2.22/ld/Input-Section-Example.html