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.