IAR linker: too smart

Instead of defining away extern my instinct would be to put the variable definitions in eeprom.c and leave the declarations in eeprom.h. Then you could initialize the variables in eeprom.c and have a better chance that the linker would leave them alone. I'm assuming that you chose not to do that since you have the __no_init attribute, which, I'm guessing, puts the variables in a non-initialized segment.

Maybe that's the problem - have you checked to see what happens without __no_init? Is it because EEPROM can't be initialized?

Andrew

andrew queisser schrieb:

Hi Andrew, the __no_init is required if I use the #pragma dataseg. If I omit it, I get a warning and the variables are placed into the standard data segment. Further, EEPROM variables cannot be initialized by the compiler, linker or loader, as there is a special procedure required to put a value into the non-volatile memory. Of course then #define extern is debatable, but I use this trick to be sure that the definitions and declarations of my variables are always the same. In the case of the IAR toolchain, this is not strictly neccessary, as the compiler emits type informations and the linker complains if there are conflicts.

Greetings Dirk

"Dirk Zabel" schreef in bericht news: snipped-for-privacy@uni-berlin.de...

I'd go for a) despite the hassles. While you're at it, you can define minimun, maximum and default values for all your parameters stored in e2prom. Have them initialized with defaults (factory reset), and keep them within defined minimum and maximum allowed values when users change settings etc. Run a sanity check as part of the start up. Things like that can make life a lot easier. Okay, you need to have the space for such extras, but if you can afford it...

--
Thanks, Frank.
(remove 'q' and '.invalid' when replying by email)

yes, and use the #define to overcome the problem of old code (if it's really such a problem)

e.g

#define E2_VERSION_TEXT (s.E2_VERSION_TEXT)

- schrieb:

Well, yes, but in my project there is already another software device taking care of user interface, limits and default values.

Thanks for all your comments! I think, this looks best so far. Quite a lot of definitions (hope there will be no symbol table overflow in the preprocessor), but with todays memory sizes it should not be a problem. And all the defintions can be put into one file (eeprom.h), this is nice.

But why on earth his this linke no option to switch off unwanted optimization?

Greetings Dirk

Is the problem is in getting the EEPROM values into HEX, or does the linker 'reshuffle' the deck for you, by removing unused data ?

If the latter, then you could just SUM all EE variables into one expression/load - that way, you get around this weakness, as the variables are references

eg DummyLoad = VERY+LONG+SUM+OF+ALL+EE+NAMES

If you are lucky, and place that into a never called function, then then linker might throw that away (unused), but not the names :)

-jg

I find it hard to believe that you asked the right question. I've seen IAR support answer exactly this question, when it was asked the MSP430 ml.

Use the __root keyword, this is what it's for. The linker does garbage collection, including only those things that are actually used, and __root adds a "root" to the gc. A root is a thing that you declare to be needed even if the gc can't see it being used.

It's documented in the manual in the same place that __no_init is.

Clifford Heath.

Thanks to Clifford Heath, the __root keyword helped. I should have seen this, as it is documented in the compiler reference manual. :-(

The question I asked was "is there any way to prevent the linker from this optimization". The answer was "no, there isn't one (only -q for version 4.10 of the ARM compiler)". Maybe I should have asked for a compiler (not linker) setting, but if I had known that the linker options are the wrong place to look I should have found the answer by myself.

Anyway, thank you very much!

Greetings Dirk

Any code which uses the preprocessor to redefine a keyword like "extern" is incorrect code. It doesn't matter whether it works or not - it's still so bad that any experienced reviewer would reject it outright.

IAR support are not famed for being helpful - on the other hand, their tools are well known for making correct and efficient code. The compiler (and linker) is doing exactly the right thing - if you declare variables that are never used, then the compiler and/or linker is free to remove them - they have no effect on the running of your program. You might think that the declarations have an effect on the addressing in eeprom - but that is not true. The order you declare or define data has no defined effect on the order in memory. For many targets, compilers will re-order the data for better alignment or padding. So even if you manage to persuade the tools to keep the unused data, you are getting a false sense of security - a new compilation could re-arrange the data.

The easiest way to get the effect you are looking for is to define a single structure for all the eeprom-based data, and ensure that it is linked to one specific address (solution "a" below). If you want to access struct members without having to add "s." in front of them, you could use #defines to avoid it (although it is almost certainly best to correct the old code rather than add hacks around it).

Solution (b) would not work (as explained above). Solution (c) is perfectly reasonable (although more effort than (a)), and solution (d) is again possible, but lots of effort to do well.

While we're on the subject of linkers...

What is it about linkers these days and relocatable code placed at upload time ? I can't seem to get an absolute code listing anymore.

Freescale (code terrorist) , IAR (arm) for example.

How are they "located" at upload time ? Can I still get listings with meaningful code placement ?

Thanks, bob

May I ask why that label? (I am not using Freescale tools at this time, but one never knows.)

There are several things I don't like about it, but especially the DSP

56FXXX compiler version... I couldn't get the output I wanted, like a decent list output file, let alone an absolute listing (which is why my question) Their support sucked for this version where I had lots of questions... No forums or users groups to ask questions really... When I did try to ask questions on a small yahoo group, no answers. And the forum was moderated so my question didn't show up for a few days.

When I sent in questions to support at freescale, it would take 6 days to get an answer and then they wouldn't usually understand my question so it took another 4 to 6 days to get another answer. Not always the right answer. Other little things about the interface they need to clean up as well.

I also just got through with a project using CW for a 9S08QG8 project but it didn't give me too many problems, luckily except that I was happy to be able to remove it the other day finally. However, Code Warrior leave MANY MANY entries in the windows registry and after uninstalling either version, I have to run a registry cleaner afterwards to remove all the entries. Otherwise, the PC will run slower. THAT's terror !

That's part of it anyway. bob

Code Terrorist, play on the real name Code Warrior.

Add, CW also registers itself as the default program to open about 25 different file types. MAYBE OK, if you only used their tools, but how many of us use multiple tools from many different vendors. CW (Metrowerks) is the only tool chain that I have ever loaded that assumes you run only their tools. I am still finding messed up file associations 2 years later.

Jim

I believe that cleaning the registry after CW has been un-installed will help with the file name associations. I'd better take a look myself though.

bob

If you have to use the CW stuff then that isn't an option. I have to support some older PalmOS stuff so un-installing it isn't an option.