Re: IAR linker: too smart



Dirk Zabel wrote:
Hi,
I am using the IAR toolchain for our Renesas M16C based project. The device uses a lot of configuration data which are stored within an eeprom. In order to define the placement, I have something like this:
eeprom.c:
#pragma dataseg="E2PROM_DATA"
#define extern /* empty */
#include "eeprom.h"
#pragma dataseg=default
/* EOF */
and
eeprom.h:
extern __no_init unsigned char MBUS_exist;
extern __no_init char E2_VERSION_TEXT[20];
extern __no_init unsigned char CAN_exists;
extern __no_init unsigned char MBUS_exists;
/* and so on. */
/* EOF */


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.


I tell the linker to place the E2PROM_DATA segment where the eeprom is mapped into the address space and can use the data from other c sources by including eeprom.h
BUT
The linker throws away all variables in eeprom.h which are not used anywhere in the projet (there is NO OPTIMIZATION selected!!). This is really bad, since I need a stable address mapping for all configuration data; there might be parameters which may be needed in later software versions; sometimes I build testversions which do not contain all parts. I allways need the variables at the same adresses.

I did already asked the IAR support, but did not get a usable answer (they told me to use volatile, but this does not change anything).


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.


I see the following approaches:
a) define a big struct which contains all variables and put that struct into E2PROM_DATA
b) put dummy references to all variables into my project
c) define the variables in some assembler source.
d) the IAR toolchain allows to put variables at numerically known addresses, I could place every variable at some pre-calculated address

a) I would have to change all code referring to (say) E2_VERSION_TEXT to s.E2_VERSION_TEXT (where s is the name of the struct variable). Since my project contains lot of old code, this is not very good.
b) ugly, blows up my project with "useless" code (the linker is quite "smart", you have to DO something with a variable or the code is optimized away).
c) ugly and dangerous, I have to keep the assembler definitions and c declarations in sync.
d) IMHO address calculations should be done by tools, not by programmes due to possible errors.

Has anyone some better idea?


Greetings
Dirk Zabel

.



Relevant Pages

  • Re: sizeof struct returning unexpected results
    ... > to just declare the elements of the struct in the order in which they ... > this struct to a file produces unexpected results. ... > int is 32 bits. ... your compiler has determined they must be aligned on. ...
    (comp.lang.c)
  • Re: extern global variable defined within namespace
    ... I'm amazed your compiler compiles that without ... You are using the syntax to declare a global variable, ... >>resolve to the struct X in the same namespace. ...
    (comp.lang.cpp)
  • Re: structures....
    ... code was declared in the ACM152.h file, the compiler did not see it ... In one place it's a struct tag, in another it's a typedef. ... If you declare z as INPUT * this code is ok. ...
    (microsoft.public.vc.language)
  • Re: Why "segmentation fault"?
    ... > OK, so I can't be sure that the problem is with my struct, damn! ... > I'd like to declare my variables the right way. ... Moreover, the compiler always works only on a single C file, never ... int total_accepted; ...
    (comp.os.linux.development.system)
  • Re: komplexes Problem mit Funktionszeigern
    ... Die Funktion gibt einen struct "by value" zurueck und bei der ... am Borland Compiler, da der Microsoft Compiler ... Man kann Argumente fuer eine Funktion z.B auf dem Stack uebergeben. ... Das funktioniert natuerlich nur fuer "Basis Typen" die in ein Register passen. ...
    (de.comp.lang.c)