C++ Constructors/Destructors Not Called

[oclyke]

Subject of the issue

When creating classes, such as Uart for Serial communication, the constructor/destructor functions are not called appropriately. For example the line Uart Serial(parameters) should create a Uart object called Serial with parameters stored appropriately as members of the object, however the members are uninitialized and read back as 'zero' without manually setting them (which violates the expectation of C++). This issue affects all development efforts using C++ constructs and so should receive the highest priority.

Your workbench

• What platform are you using?
  • Windows 10, Arduino 1.8.9, using the Arduino SAMD Core ( 1.6.20 ) for the Arm build tools.
• Are there any additional details that may help us help you?

Steps to reproduce

Tell us how to reproduce this issue. Please post stripped down example code demonstrating your issue to a gist.

class testClass{
  public:
    testClass(char parameter);
    char x;
    void printX( void );
};

testClass::testClass(char parameter){
  x = parameter;
}

void testClass::printX( void ){
  am_util_stdio_printf("Test class object has X = %d\n\n", x);
}

testClass myTestClassObj( 13 );

void setup() {
  // put your setup code here, to run once:
  am_util_stdio_printf("SparkFun Arduino Apollo3 C++ Constructor Issue Example\n");
  am_util_stdio_printf("Compiled on %s, %s\n\n", __DATE__, __TIME__);
  am_bsp_uart_string_print("Hello, World!\r\n\n");  // Sting_print has less overhead than printf (and less risky behavior since no varargs)

  myTestClassObj.printX(); // Should print with x = 13 (fails, not initialized)
  myTestClassObj.x = 5;
  myTestClassObj.printX(); // Should print with x = 5 (successful, x is set manually - but does not meet C++ expectation)

  testClass localTestClassObj( 13 );  // Constructed 'manually' in main application
  localTestClassObj.printX();         // This succeeds (prints with x = 13) because it does not rely on initialization code (__libc_init_array()) to call constructor
}

void loop() {
  // put your main code here, to run repeatedly:

}

Expected behaviour

Using constructors should correctly set up the values within the object

Actual behaviour

Constructors are not called automatically. They CAN be called manually, but then the scope of that class is restricted.

Further Thoughts:

The Constructor/Destructor feature of C++ is (at least somehow) tied in with the function __libc_init_array() and some entries in the linker script (?) called (something like) .init_array_start and .init_array_end. These entries are lists of all the construction function pointers to call and presumably what arguments to pass to them and what is expected out of them.

Adding the __libc_init_array() function into the startup code (cores/arduino/ard_sup/main.cpp) results in a linker error "init.c:(.text.__libc_init_array+0x22): undefined reference to `_init'"

Currently looking for a solution to this. Any thoughts/expertise are welcome!

[oclyke]

Update:

I've done a lot of research into this problem, and learned a lot. The solution is still evading me but I'll jot some notes down here for reference.

How C++ Programs Start Up

Languages like C and C++ have a specification that lays out exactly what the environment should look like when executing a program. Between starting a program and getting to main() there is a some amount of set up to do. One key step for C++ that differs from C is to call all the global constructors so that the globally scoped objects begin with the proper values. This is done by looping over a block of function pointers in memory that are (insert method adjective here) provided by the compiler (gcc in our case). This looping is standardized in the the 0th C runtime library, often called 'crt0.o', 'crtbegin.o', or a similar flavor.

A more in-depth explanation is here

How Does that Apply Here?

We're migrating from a pure-C development environment and trying to add C++ features. Our compiler already handles .cpp (or .cc) files and compiles them appropriately. What's left is to properly set up the C runtime environment for C++, and immediately that means ensuring that all constructors are aggregated in memory and then called before main()

Fortunately Pete Warden + Team at Google have already made this happen for TensorFlow Lite Micro so we can use that as a reference. Here are the differences that I could spot:

1. The linker script has been modified to include:

	/* These are the C++ global constructors.  Stick them all here and
	 * then walk through the array in main() calling them all.
	 */
	_init_array_start = .;
	KEEP (*(SORT(.init_array*)))
	_init_array_end = .;

	/* XXX Currently not doing anything for global destructors. */

1. There are a few additional linker flags specified in the Apollo3-specific makefile tensorflow/lite/experimental/micro/tools/make/targets/apollo3evb_makefile.inc

   1. -fno-exceptions
   2. -nostdlib
   3. --specs=nano.specs
   4. -t
   5. -lstdc++
   6. -lc
   7. -lnosys
   8. -lm

2. The Apollo3-specific makefile also includes an additional object file - promisingly named crtbegin.o from tensorflow/lite/experimental/micro/tools/make/downloads/gcc_embedded/lib/gcc/arm-none-eabi/7.3.1/thumb/v7e-m/fpv4-sp/hard/crtbegin.o
   in the list of LIBS.

Applying this to Arduino

I took these steps to try to set up the C runtime for the Apollo core:

1. Borrowed the function __libc_init_array() from other Arduino cores (specifically the SAMD core, because SAMD are Cortex-M based microcontrollers as well) and placed it before we enter setup().
   • Linker exits with an undefined reference to _init().
2. To solve linker I add TF linker flags (above) and a 'C runtime' file from (for example) # {runtime.tools.arm-none-eabi-gcc.path}/lib/gcc/arm-none-eabi/4.8.3/armv7e-m/fpu/crti.o' where {runtime.tools.arm-none-eabi-gcc.path} is pointing to the ARM tools for the SAMD core
   • Now linking completes but execution hangs in the __libc_init_array() function.

So, that's where this problem stands for now. I presume that the code hangs in the __libc_init_array() function because of a mis-communication between it and the linker script. (i.e. the .init_array section in memory either doesn't exist at all, doesn't exist at the expected location, or isn't being filled out by gcc, or any combination of the above!)

Next Steps

1. Move the problem out of Arduino by trying to get C++ functionality directly in the AmbiqSuite SDK first
2. Try to figure out what code, exactly, is run by __libc_init_array()
3. Try to verify that constructor function pointers are being assembled in memory by GCC
4. Perhaps try manually calling all those function pointers? But ideally would use a standard C-runtime setup library. Is there a proper function to call to get it set up?

[edspark]

Great write up! This drops me deep in the C/C++ melodrama as it's unfolding.

[oclyke]

Solved with this commit 283d6f7

Stumbled across a solution on the Mutable Instruments Forum

It doesn't look like much, but there was a lot to learn about the C++ runtime and startup process before finding this to be confident that this is a proper solution.