AVR Freaks

I just told you how to "repair" this. In the latest code put them all in ONE struct. You get to control the layout within the struct so can make it match the deployed layout. While it's pretty certain the linker will place that one struct variable at 0x810000, if there's any doubt you can force it there with a section declaration and then a -Wl,-section-start=0x810000. But, as I say, with just one struct variable the linker will place it there anyway.

All you then have to worry about is your struct layout matching the previous layout the linker happened to generate.

Wonder how linker just picked a random address.

There is nothing "random" about  it. It is 100% determinisitic. It just so happens that it is a DIFFERENT deterministic layout compared to the ancient version of compiler/linker you were using.

(BTW why 4.7 and not at least 4.8 or even 4.9?)

Yes.

I was under the impression that it was legal for the compiler to rearrange

Then how could you do things like this:

http://www.tenouk.com/Module43.html

Almost everything in TCP/IP is defined in term of C struct{}'s with a fixed layout. One PC reads another's TCP and IP packets by applying the same struct{} layout to both. The "issues" that may be involved in doing this are just packing/alignment and possible issues of endianism interpretation.

It's interesting to note, however, that when Chan attempts to read FAT data structures in FatFs he chooses to do so using "David's method" - that is simply #define'ing offsets to the various fields - so that he can avoid issues like alignment/packing.

So it's probably 50:50 as to which one is the "right" solution.

I always come back to C variables in SRAM. When you write:

int n = 12345;
long l = 0xBABEFACE;
char c = 'X';

int main(void) {
 ...

you'd never think about where the linker might be choosing to hold n, l and c. It picks some magic location for you and you just accept what it chose.

I can see how EEPROM is a bit different in that it is maintained between one build of software and another but personally I'd still let the linker take care of it for you because if you get into the realms of:

#define N_LOC 100
#define L_LOC 102
#define C_LOC 105

you've now taken on the manual job of doing what just comes naturally to the linker. It's far to easy to make the kind of error I just did ;-)

(yes the 105 truly is the "deliberate error" in that to make a point!).

however this will not solve the problem if non-volatile memory is used, as in my case. Even the location at which the structure is stored is important.

And why do you believe that to be true (it isn't by the way). I know David said:

You do realise that the struct method is not completely safe.   e.g. a later Linker might choose to allocate EEPROM starting at a different location to 0.

But he's just messing with your mind ;-)

As I say your only potential problem when putting all vars in a single struct is whether you can guarantee that struct is located at 0 in EEPROM. I think you can rely on the linker to start counting from 0 in any address space myself but if you thought there were any doubt then use an __attribute__((section(".myeesect"))) on the struct (and forget "EEMEM" which itself is just __attribute__((section(".eeprom"))) anyway) and then in the linker use -Wl,-section-start=.myeesect=0x810000 and that will do pretty much what was happening with .eeprom anyway. You'd also need to modify the avr-objcopy that creates the .eep file.

So programmer has really no control over Compiler/Linker

Now you are getting silly - the programmer has TOTAL control over the compiler and linker. In fact GCC possibly offers the most configurable compiler and linker in the world. There aren't many people who understand all of the hundreds (possibly thousands?) of command line options the tools support! (and I haven't even mentioned things like linker scripts).

Oh and the thing about pointers to EEPROM is a complete red-herring.

David was very clear in his display of two examples above. You either use struct{} or you #define and either is very simple. I'm not entirely sure why you are making a mountain out of this particular mole-hill?

Oh and you know the overlapping thing I warned about with #define's? You could mitigate a lot of the risk with something along the lines of "+sizeof(var_type)" to place varN+1 after varN of var_type.

I use struct because I need to know where things are in EEPROM - the whole point of using EEPROM is that I can go in and change parameters without recompiling / reflashing.

The other point I would make is that as well as using struct you can also initialise like below. Sorry if it's already obvious to everyone, it wasn't to me (momentary lapse).

struct  
{
	uchar	dbSteps;			// how much debouncing to do
	uchar	lineDelay;			// uS to wait for capacitance of wires
	// which channels are half-octaves not full ones
	uchar	halfOcts;
	// start C# note for each keyboard to avoid transposing
	uchar	baseNote[NUM_CHANNELS];
	uchar	baseChan[NUM_CHANNELS];
	// which octaves to invert? (1 = invert, bitwise)
	uchar	invOct[NUM_CHANNELS];
	// and which octave has extra note
	uchar	extraNote[NUM_CHANNELS];
}	eevars	EEMEM = 
{
	1,			// dbSteps
	20,			// lineDelay
	3,			// halfOcts
	{37, 73, 49, 49, 49, 13},	// baseNote
	{1, 1, 2, 3, 4, 5},			// baseChan
	{0, 0, 0, 16, 0, 0},		// invOct
	{1, 0, 0, 0, 0, 0}			// extraNote
};

Sorry yes, I should have prefaced my reply with "This won't help the OP, but for the benefit of anyone else who, like me, stumbles across this thread by searching on 'EEPROM reversed order' or similar..."

Thanks for the other technique, I hadn't thought of that.