Order of variables in specific sections when enabling optimization in gcc

[David Brown]

On 07/03/2019 14:50, Freddie Chopin wrote:
> On Thu, 2019-03-07 at 07:00 -0600, Segher Boessenkool wrote:
>> On Thu, Mar 07, 2019 at 01:15:47PM +0100, Freddie Chopin wrote:
>>> On Thu, 2019-03-07 at 06:08 -0600, Segher Boessenkool wrote:
>>>> You probably should use a linker script for this.
>>>
>>> You think of anything better than placing each variable in its own
>>> section and placing them manually in the linker script in the order
>>> I
>>> like? I would like to avoid any messing with linker script if
>>> that's
>>
>> You can refer to separate variables in the linker script, you don't
>> have
>> to put them each in their own section.
> 
> How should I do that? Do you think of giving absolute addresses to
> individual symbols? This is not very convenient, as then I would also
> have to think about their size. This will also not play so well with
> name-mangling (the project is in C++).

You can avoid the name-mangling by declaring symbols as extern "C".  I 
don't think variable names are mangled anyway - only function names. 
(Unless you are using C++14 template variables, anyway.)

> 
>>> possible... If there's nothing better I may end up using suffixes
>>> ("section.1", "section.2", "section.3", ...) and sort the sections
>>> in
>>> the linker script (`*(SORT(.section.*));`), but I would still
>>> prefer to
>>> solve that in the source file only.
>>
>> You could try putting all those vars in a struct.  In principle the
>> compiler is free to mess that up, too, though, but this is less
>> fragile,
>> and easier to work around should it break.
> 
> Yes, this is also an option, but this is not very convenient for me, as
> then each user of each variable would get all the headers required for
> completely unrelated variables (like definitions of classes and so on).
> Not an issue now, but this also won't work if one variable needs to be
> used from a C file and another one is a C++ class. This just does not
> scale well..
> 

How about:

battery_ram.h
-------------
#include <stdint.h>

struct raw_battery_ram_t {
	uint32_t programKey;	// Constant for type of program
	uint32_t structVersion;	// To allow transparent upgrades

	uint64_t paramsBlock[10];
	uint64_t scratchpad[20];
	uint64_t log[20];
};

extern raw_battery_ram_t raw_battery_ram;


battery_ram.c
-------------
#include "battery_ram.h"

raw_battery_ram_t raw_battery_ram __attribute__((section("battery_ram")));


params.h
--------
#include "battery_ram.h"

struct params_t {
     uint32_t noOfWoozles;
     uint16_t sizeOfThingies;
     uint16_t countOfThingies;
     uint64_t secretKey;
};

static params_t& params = *(reinterpret_cast<params_t*>
		(&(raw_battery_ram.paramsBlock)));

static_assert(sizeof(params) <= sizeof(raw_battery_ram.paramsBlock));


othercode.c
-----------
#include "params.h"

void processWoozles(void) {
	for (uint32_t i = 0; i < params.noOfWoozles; i++) {
		toogleWozzle(i);
	}
}



This means that the information in the common "battery_ram.h" header is 
restricted to basic blocks, not type details.  Any types needed for the 
parameter block are only visible in "params.h", while any types needed 
for the scratchpad block are only visible in the "scratchpad.h".  A 
slightly ugly reinterpret_cast is used to map the logic type structure 
onto the actual storage space (a placement new would be an alternative 
option).  Static asserts are used to spot overruns (the size of the 
spaces allocated in the raw struct have to be entered manually).


>> If you use LTO or some other whole-program optimisation, that won't
>> save you.  Hiding things from the compiler so it cannot assume
>> anything
>> about it breaks as soon as the compiler gets more smarts (if it ever
>> worked).  Telling the compiler that something *is* accessed some way
>> that it cannot see: that is fool-proof and future-proof.
> 
> But these variables are used. I'm not hiding anything, they are used,
> usually their address is embedded withing other objects, so they are
> used "as much as possible" (;
> 
> Regards,
> FCh
> 
>