Comment on page
Static Objects
Let's analyse the code that initialises static objects. test_cpp_statics is a simple application that has two static objects, one is in the global scope, the other is in the function scope.
class SomeObj
{
public:
static SomeObj& instanceGlobal();
static SomeObj& instanceLocal();
private:
SomeObj(int v1, int v2);
int m_v1;
int m_v2;
static SomeObj globalObj;
};
SomeObj SomeObj::globalObj(1, 2);
SomeObj& SomeObj::instanceGlobal()
{
return globalObj;
}
SomeObj& SomeObj::instanceLocal()
{
static SomeObj localObj(3, 4);
return localObj;
}
int main(int argc, const char** argv)
{
static_cast<void>(argc);
static_cast<void>(argv);
auto& glob = SomeObj::instanceGlobal();
auto& local = SomeObj::instanceLocal();
static_cast<void>(glob);
static_cast<void>(local);
while (true) {};
return 0;
}
Note, that compiler will try to inline the code above if implemented in the same file. To properly analyse the code that initialises global variables, you should put implementation of constructor and
instanceGlobal()/instanceLocal() functions into separate files. If -nostdlib option is passed to the compiler to exclude linking with standard library, the compilation of the code above will fail with following error:main.cpp:(.text.startup+0x1c): undefined reference to `__cxa_guard_acquire'
main.cpp:(.text.startup+0x3c): undefined reference to `__cxa_guard_release'
It means that compiler attempts to make static variables initialisation thread-safe. The get it compiled you have to either implement the locking functionality yourself or allow compiler to do it in an unsafe way by adding
-fno-threadsafe-statics compilation option. I think it is quite safe to use this option in the bare-metal development if you make sure the statics are not accessed in the interrupt context or have been initialised at the beginning of main() function before any interrupts are enabled. To grab a reference to such object without any use is enough: auto& local = SomeObj::instanceLocal();
static_cast<void>(local);
Now, let's analyse the initialisation of
globalObj. The .init.array section contains pointer to initialisation function _GLOBAL__sub_I__ZN7SomeObj9globalObjE.Disassembly of section .init.array:
00008180 <__init_array_start>:
8180: 00008154 andeq r8, r0, r4, asr r1
The initialisation function loads the address of the object and passes it to the constructor of
SomeObj together with the initialisation parameters (“1” and “2” integer values).00008154 <_GLOBAL__sub_I__ZN7SomeObj9globalObjE>:
8154: e59f0008 ldr r0, [pc, #8] ; 8164 <_GLOBAL__sub_I__ZN7SomeObj9globalObjE+0x10>
8158: e3a01001 mov r1, #1
815c: e3a02002 mov r2, #2
8160: eaffffee b 8120 <_ZN7SomeObjC1Eii>
8164: 00008168 andeq r8, r0, r8, ror #2
00008168 <_ZN7SomeObj9globalObjE>:
...
The code above loads the address of the global object (
0x00008168) into r0, and initialisation parameters into r1 and r2, then invokes the constructor of SomeObj.Please remember to call all the initialisation functions from
.init.array section in your startup code before calling the main() function.In the linker file:
.init.array :
{
__init_array_start = .;
*(.init_array)
*(.init_array.*)
__init_array_end = .;
} > RAM
In the startup code:
;@ Call constructors of all global objects
ldr r0, =__init_array_start
ldr r1, =__init_array_end
globals_init_loop:
cmp r0,r1
it lt
ldrlt r2, [r0], #4
blxlt r2
blt globals_init_loop
;@ Main function
bl main
b reset ;@ restart if main function returns
However, if standard library is NOT excluded explicitly from the compilation, the
__libc_init_array provided by the standard library may be used: ;@ Call constructors of all global objects
bl __libc_init_array
;@ Main function
bl main
b reset ;@ restart if main function returns
Let's also perform analysis of initialisation of
localObj in SomeObj::instanceLocal().000080e4 <_ZN7SomeObj13instanceLocalEv>:
80e4: e92d4010 push {r4, lr}
80e8: e59f4028 ldr r4, [pc, #40] ; 8118 <_ZN7SomeObj13instanceLocalEv+0x34>
80ec: e5943008 ldr r3, [r4, #8]
80f0: e3130001 tst r3, #1
80f4: 1a000005 bne 8110 <_ZN7SomeObj13instanceLocalEv+0x2c>
80f8: e284000c add r0, r4, #12
80fc: e3a01003 mov r1, #3
8100: e3a02004 mov r2, #4
8104: eb000005 bl 8120 <_ZN7SomeObjC1Eii>
8108: e3a03001 mov r3, #1
810c: e5843008 str r3, [r4, #8]
8110: e59f0004 ldr r0, [pc, #4] ; 811c <_ZN7SomeObj13instanceLocalEv+0x38>
8114: e8bd8010 pop {r4, pc}
8118: 00008168 andeq r8, r0, r8, ror #2
811c: 00008174 andeq r8, r0, r4, ror r1
The code above loads the address of the flag that indicates that the object was already initialised into r4, then loads the value into r3 and checks it using
tst instruction. If the flag indicates that the object wasn't initialised, the constructor of the object is called and the flag value is updated prior to returning address of the object. Note that tst r3, #1 instruction performs binary AND between value r3 and integer value #1, then next bne instruction performs branch if result is not 0, i.e. the object was already initialised.CONCLUSION: Access to global objects are a bit cheaper than access to local static ones, because access to the latter involves a check whether the object was already initialised.
And what about destruction of static objects with non-trivial destructors? Let's add a destructor to the above class and try to compile:
class SomeObj
{
public:
~SomeObj();
…
}
Somewhere in *.cpp file:
SomeObj::~SomeObj() {}
This time the compilation will fail with following errors:
CMakeFiles/03_test_statics.dir/SomeObj.cpp.o: In function `SomeObj::instanceLocal()':
SomeObj.cpp:(.text+0x44): undefined reference to `__aeabi_atexit'
SomeObj.cpp:(.text+0x58): undefined reference to `__dso_handle'
CMakeFiles/03_test_statics.dir/SomeObj.cpp.o: In function `_GLOBAL__sub_I__ZN7SomeObj9globalObjE':
SomeObj.cpp:(.text.startup+0x28): undefined reference to `__aeabi_atexit'
SomeObj.cpp:(.text.startup+0x34): undefined reference to `__dso_handle'
According to this document, the
__aeabi_atexit function is used to register pointer to the destructor function together with pointer to the relevant static object to be destructed after main function returns. The reason for this behaviour is that these objects must be destructed in the opposite order to which they were constructed. The compiler cannot know the exact construction order for local static objects. There may even be some static objects are not constructed at all. The __dso_handle is a global pointer to the current address where the next {destructor_ptr, object_ptr} pair will be stored. The main function of most bare metal applications is not supposed to return and global/static objects will not be destructed. In this case it will be enough to implement the required function the following way:extern "C" int __aeabi_atexit(
void *object,
void (*destructor)(void *),
void *dso_handle)
{
static_cast<void>(object);
static_cast<void>(destructor);
static_cast<void>(dso_handle);
return 0;
}
void* __dso_handle = nullptr;
However, if your
main function returns and then the code jumps back to the initialisation/reset routine, there is a need to properly perform destruction of global/static objects. You'll have to allocate enough space to store all the necessary {destructor_ptr, object_ptr} pairs, then in __aeabi_atexit function store the pair in the area pointed by __dso_handle, while incrementing value of later. Note, that dso_handle parameter to the __aeabi_atexit function is actually a pointer to the global __dso_handle value. Then, when the main function returns, invoke the stored destructors in the opposite order while passing addresses of the relevant objects as their first arguments.To verify all the stated above let's take a look again at the generated code of initialisation function (after the destructor was added):
00008170 <_GLOBAL__sub_I__ZN7SomeObj9globalObjE>:
8170: e92d4010 push {r4, lr}
8174: e59f4020 ldr r4, [pc, #32] ; 819c <_GLOBAL__sub_I__ZN7SomeObj9globalObjE+0x2c>
8178: e3a01001 mov r1, #1
817c: e1a00004 mov r0, r4
8180: e3a02002 mov r2, #2
8184: ebffffeb bl 8138 <_ZN7SomeObjC1Eii>
8188: e1a00004 mov r0, r4
818c: e59f100c ldr r1, [pc, #12] ; 81a0 <_GLOBAL__sub_I__ZN7SomeObj9globalObjE+0x30>
8190: e59f200c ldr r2, [pc, #12] ; 81a4 <_GLOBAL__sub_I__ZN7SomeObj9globalObjE+0x34>
8194: e8bd4010 pop {r4, lr}
8198: eaffffe9 b 8144 <__aeabi_atexit>
819c: 000081a8 andeq r8, r0, r8, lsr #3
81a0: 00008140 andeq r8, r0, r0, asr #2
81a4: 000081bc ; <UNDEFINED> instruction: 0x000081bc
00008140 <_ZN7SomeObjD1Ev>:
8140: e12fff1e bx lr
000081bc <__dso_handle>:
81bc: 00000000 andeq r0, r0, r0
Indeed, the call to the constructor immediately followed by the call to
__aeabi_atexit with address of the object in r0 (first parameter), address of the destructor in r1 (second parameter) and address of __dso_handle in r2 (third parameter).CONCLUSION: It is better to design the “main” function to contain infinite loop and never return to save the implementation of destructing global/static objects functionality.
Last modified 3yr ago