On Thu, 2019-03-07 at 14:05 +0100, David Brown wrote: > The -fno-toplevel-reorder switch can be handy too - it will stop > re-ordering within a translation unit. Great - I'll try that soon (; This seems to be what I was looking for! > However, if you are using LTO or -fdata-sections and the > --gc-sections linker option, variables that are not needed get > eliminated. (Note that this could happen even if they are actually > used, if the compiler can figure out that the storage is not needed.) --gc-sections and -fdata-sections does not affect variables for which I explicity set the section. They are not removed, even if not used (I'm not using LTO). > I have seen people try to use section attributes and careful linker > setups to get consistent memory layouts between program versions. > (Usually it is eeprom, rather than battery backed ram, but the > principle > is the same.) It is often possible to get a reasonable solution - it > is > rarely possible to get a good and reliable solution that caters for > all > possibilities. Typically things break down when you want to add a > new > variable. I would think that as long as all of such variables are in single source file and the compiler keeps the order (whatever order that is) then everything will be fine. > My personal preference is to make a struct definition that holds > /all/ > the variables in the special area. This makes it easy to track, and > easy to be sure that you have everything where you expect it. My > struct > here starts with some metadata - an indicator of the program type (if > you have more than one program for the same card), a struct version > number (so that a new program version can re-use old data while > knowing > that new data might not be properly initialised), and typically > stamps > and CRC's for allowing multiple versions of the data. (That is > relevant > for eeproms that take some time to store the data, when you might > have a > power fail during write - it is less relevant for battery backed > ram.) Yes, as I wrote in another reply, this indeed is also an option, but I would prefer something simpler if possible (; I'm fine with keeping the variables in simple source file, but possibly as "independent" objects, so that I can have separate header for each variable. Regards, FCh
