arm-none-eabi-g++ does not initialize class static members in code generated on debian

Here is full project.

folders
build.debian
build.ubuntu
contains .elf .bin .o files
compiled in OS mentioned.

This could be related to #1560533.

There is difference: in my case my static constructors works well. Only std::list static member is affected.

Understanding that this issue has sat here for a while, I'd like to make an observation.

I wonder if we're not talking about the same sort of initialization. The initialization of statics is performed by the run-time and not the compiler. So, assuming that the problem here *is* initialization, it is hard for me to imagine that the difference is between ubuntu and debian per-se. Instead, I'd expect that there is a difference with the installation and paths of the compilers on the two systems.

There are three ways that statics are initialized, barring changes from the default linker script. For BSS, the RAM region is zeroed. For static-ly initialized scalars and POD aggregates, data may be copied from the text segment into RAM. For objects that invoke constructors, there is a list of calls that the runtime invokes before starting main.

The lk:led::led_list symbol is BSS on ubuntu:

  $ nm -C testservo.elf | grep led_list
  080003bc t _GLOBAL__sub_I__ZN2lk3led8led_listB5cxx11E
  20000a0c B lk::led::led_list[abi:cxx11]

as well as debian:

  $ nm -C testservo.elf | grep led_list
  08000910 t _GLOBAL__sub_I__ZN2lk3led8led_listB5cxx11E
  20000a3c B lk::led::led_list[abi:cxx11]

Though at different addresses.

There appears to be a constructor for this object in led.hh that would be invoked by the declaration of an object in main:

  lk::led led0(lk::gpio_c, 13);

You can also verify that there are constructors by checking the symbols in the elf files.

  $ nm ../*/testservo.elf | grep __init_array
  080084a4 t __init_array_end
  08008490 t __init_array_start
  080084a4 t __init_array_end
  08008490 t __init_array_start

The arrays are the same size in both builds, which is good.

Before we decide this is a failure of initialization, it is worthwhile breaking the program on _main and looking at the memory where this symbol lives. My hunch is that initialization is being performed and we're seeing corruption instead.

Without reviewing the build, I could only guess that, perhaps, the order of linking differs on the two systems which results in a different location for the symbol. This different is probably worth investigating. There may also be an ambient difference in the build such as a pathname or other datum pulled from the build that is changing the location of the symbols.

Cheers

This example code is broken. The language does not guarantee the order in which globals are initialized. You could evade that problem by using function local statics, for things like the led_list.

Or simply pick a better design.