[ell-i-developers] Re: Problem with Array Initialization

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Fri, 7 Mar 2014 02:25:39 +0200

> Some part of my code, I suppose some array, is generating some initialization 
> routine. From my previous experience with the SPI API, I know that if an 
> array is not declared adequately, gcc tries to generate code to actually copy 
> it (IIRC it requires memcpy that is not part of the arm-none-eabi standard 
> libraries).

My guess it is this line:


I think you want to have a reference there, not a copy:

  const SPIClass & spi_;

Note the ampersand.  In general I think having references is one of the more 
confusing things in C++.  While at the syntax level a reference looks like the 
thing itself, actually at the code level a reference works like a const 
pointer.  Of course, constant propagation can get rid of it, but if the 
compiler cannot do constant propagation on it, e.g. because the original is 
defined in a different compilation unit (and you are not using LLVM link-time 
optimisation), then the generated code will behave the same way as if you had 
had a constant pointer to the original instead of a reference.

In more concrete terms, these produce identical machine code:
  const SPIClass *const spi_;  ...   spi_->foo = bar;
  const SPIClass &      spi_;  ...   spi_.foo  = bar;

But if you are using a copy of the object instead of a reference, the generated 
code is quite different.  

But then, if you have a constant object (as you do here), and if the compiler 
knows the original at the compile time (which apparently is not the case here), 
then aggressive constant propagation may get rid of the constant object 
completely.  In that case you won't notice the difference.

The linker can fix a reference, as the compiler generates simply a symbol table 
entry for the reference.  To see how, use nm.  The linker cannot fix an object 
copy; for that the compiler generates a static initialiser.

I have made the same mistake a few times, in different disguises.  It is always 
hard to figure out the culprit.

> (1) Is there a concrete or specific way of declaring arrays and other 
> structures to make them allocated correctly and do not rely on initialisation 
> routines?

Well, no.  You have done most things right, including declaring the constructor 
constexpr.  However, there are no guarantees in C++ that the compiler will do 
the "right thing," i.e. compile-time initialisation.  The compiler is free to 
generate a startup-time call to the constructor aka a static initialiser.  
That's the reason why we have the assert in the linker script in the first 

Or maybe there is, but the "way" is quite complicated, you basically have to 
know your compiler well enough. Then, we ware using (on the Mac) both LLVM and 
GCC, so you need to know them both. :-)


PS.  At least for the production version, I think it may be better to jump to 
the reset vector at abort() instead of having a busy loop, cf.


A busy loop and perhaps a blinking "LED" (i.e. GPIO line) at abort is better in 
a debug version.

Other related posts: