Re: [arm-gnu] -funit-at-a-time

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

Bryce Schober wrote:
> I just realized that in our compiler upgrade from 3.3.0 to 4.0.1 (yes,
> I realize that this is a huge jump...), -O2 is breaking us. We were
> depending on the emitted order of const (non-)variables destined for
> our flash image. I now realize that this is something we probably
> shouldn't have been depending on to start with, but it seems that it
> would be a fairly common requirement for deeply embedded work. I see
> that the manual says "As a temporary workaround, -fno-unit-at-a-time
> can be used, but this scheme may not be supported by future releases
> of GCC." Should I be worried about using this workaround in the long
> term? What other method would I use to determine the emitted order of
> consts?

You're right to worry.  For example, in C++, -fno-unit-at-a-time is no 
longer supported, and you will always get the re-ordering behavior. 
We're also working on projects that may result in reordering globals to 
get better cache behavior.

There are two tricks you could use.

One trick is to put everything into a structure, like:

  struct globals {
    int i;
    int j;
  };

  static globals g;

Then, use "g.i" instead of "i".  The compiler will keep the structure 
together.  The other is to explicitly place the variables in particular 
sections (using the attribute((section("...")) syntax) and then user a 
linker script to control the section order.

Neither of these work with constants that are emitted by the compiler, 
like when you write:

  const char *s = "A string";
  const float f = 5.0f;

There's no way to control placement of those constants.

GCC should probably be augmented with an explicit placement directive of 
some kind, or a pragma to disable reordering around a block of 
variables.  We do add features like this for our customers when their 
needs are sufficiently general-purpose.

Regards,

--
Mark Mitchell
CodeSourcery, LLC
mark@xxxxxxxxxxxxxxxx
(916) 791-8304