The mysterious __libc_init_array() in Cube IDE - is it only for C++ ??

This is a feature of GCC runtime library and linker.  Yes, these things can be used to implement C++ constructors and destructors of static objects and also to initialize local data in dynamic libraries. More details in the GCC documentation (for any architecture, not specific to ARM).

>  Much of libc.a is also not re-entrant and needs to be mutexed in any RTOS environment.

This was heavily discussed in this forum (before migration). The real answer is that CubeMX/IDE provide a software component for RTOS-aware locks in newlib. Whether to use that or not, and validation, is up to developer.

"Yes, these things can be used to implement C++ constructors and destructors of static objects and also to initialize local data in dynamic libraries"

OK, same imprecise answer as all over google :beaming_face_with_smiling_eyes:

So is it C++ only, or not?

Disassembling libc.a should yield the answer. Of course there are 66 (literally; just counted them) different versions of libc.a supplied with Cube IDE, according to the processor. No src for any of them. I am using a 32F417.

I have just stepped through the code (has to be done with Cube switched to displaying assembler) and there is very little code being run. There is a loop which is taken ~3 times.

The code from 306: to 31e: is executed twice. So it is not doing "nothing". My project has no C++ in it.

The whole thing is weird with 1.15.0. The STLINK V3 debugger fails as posted in the EEVBLOG thread. And when that fails, ST Utility, while programming the chip OK, also fails to deliver a running target, suggesting that code generated by 1.15.0 is faulty in some way. But when I reinstall 1.14.1 everything immediately works, including the ST Utility loading working code. And obviously without a working debugger there is no way to track down the problem.

I believe the answer is in newlib's sources (and for motivation we should interview is authors). There's probably no ST involvement there.

> The whole thing is weird with 1.15.0. The STLINK V3 debugger fails

How is this __libc_init_array- related?

JW

Yeah but which sources :beaming_face_with_smiling_eyes:

The debugger issue is unrelated, sorry - for another thread. But it does mean that with Cube IDE v1.15.0 I can't step through any code.

> So is it C++ only, or not?

Not for C++ only. It can be used in plain C, with compatible compilers that understand  __attribute__((constructor)) and __attribute__((destructor)) .  Example:

https://www.geeksforgeeks.org/__attribute__constructor-__attribute__destructor-syntaxes-c/

From above URL:

Write two functions in C using GCC compiler, one of which executes before main function and other executes after the main function.

Why is this needed (in C)? If you want to run some code before main() you just insert it in the startup.s code which calls main() at the end. Actually startup.s, in asm in Cube IDE/MX, could be done wholly in C too, AFAICT.

And if you want a function to run after main() then, ahem, you just call it after main(). I must be missing something totally obvious.

That is a circular example, however. 

If you want to run some code before main() you just insert it in the startup.s code which calls main() at the end.

I don't see the point of __libc_init_array(). You can call any C function from anywhere before main(), which is just an entry point of a void function like any other C function.

The keyword here is "magic".

It's the widespread expectation, that things should "happen" and the unfortunate urge of many influential people to provide the "magic", instead of - arguably harder, but arguably more appropriate - proper documentation/education. It's exactly the same principle as in IDEs and Cubes.

Here, the expectation is, that you should be able to run a function before main() without knowing what leads up to main, i.e. without knowledge of the startup code. Said atributes are the incantation to invoke the magic, __libc_init_array() is part of the set of mirrors which perform the magic.

JW

Jan, I accept your tongue in cheek post :beaming_face_with_smiling_eyes: but I must still be missing something big.

Why would anyone want to run a function before main() ? After all, main() is the entry point of your code. Nothing should be happening before main() - other than stuff to set up the language standards e.g. zero bss, copy init data from ROM to RAM, zero the stack (or fill with "s") for good measure, and of course load SP which is necessary before calling functions (of which main() is one). No application specific code should ever run before main().

I am talking "embedded" here, not the command line stuff whereby main() implicitly picks up argc argv arguments etc.

I know nothing about C++ but can fully understand some needs for setting up data structures.

If a function is needed to set up RAM static variables in C code (as has been alleged __libc_init_array() does, setting up stuff like stdlib printf malloc etc) why can't this go after main()? Only if you want to avoid documenting "why".

I posted some disassembled code and maybe someone has an idea what it does in C.