ARM-software
cmsis_gcc.h warnings
I'm trying to integrate CMSIS Core-M v5.4 into my project, and at first attempt I got:
In file included from xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_compiler.h:54,
from xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/core_cm4.h:162,
from xpacks/micro-os-plus-platform-qemu-cortexm/include/micro-os-plus/device.h:79,
from xpacks/micro-os-plus-architecture-cortexm/device/src/startup/initialize-hardware-early.c:33:
xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_gcc.h: In function '__cmsis_start':
xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_gcc.h:133:15: error: nested extern declaration of '_start' [-Werror=nested-externs]
133 | extern void _start(void) __NO_RETURN;
| ^~~~~~
xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_gcc.h:146:31: error: nested extern declaration of '__copy_table_start__' [-Werror=nested-externs]
146 | extern const __copy_table_t __copy_table_start__;
| ^~~~~~~~~~~~~~~~~~~~
xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_gcc.h:147:31: error: nested extern declaration of '__copy_table_end__' [-Werror=nested-externs]
147 | extern const __copy_table_t __copy_table_end__;
| ^~~~~~~~~~~~~~~~~~
xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_gcc.h:148:31: error: nested extern declaration of '__zero_table_start__' [-Werror=nested-externs]
148 | extern const __zero_table_t __zero_table_start__;
| ^~~~~~~~~~~~~~~~~~~~
xpacks/xpack-3rd-party-arm-cmsis-core-m/CMSIS/Core/Include/cmsis_gcc.h:149:31: error: nested extern declaration of '__zero_table_end__' [-Werror=nested-externs]
149 | extern const __zero_table_t __zero_table_end__;
| ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
I suggest you move the extern definitions outside the __cmsis_start() function scope.
I also suggest you enable more warnings during your tests, to catch such issues.
Here is a comprehensive example:
Fyi: flit/CMSIS_5@55eb7f258d9b1e68c70f11f7a34959bf975713d4
Not quite ready for the PR yet, it still needs to be tested.
Hi all,
I agree this is unusual. The reason for this solution was to hide the symbols from global scope. The implementation has been reviewed by Compiler experts confirming this code is fine.
This is a duplication of https://github.com/ARM-software/CMSIS_5/issues/617.
Cheers, Jonatan
... Compiler experts confirming this code is fine
Nope, as long as the compiler throws warnings, the code is not fine.
It may be legal when compiled with legacy C compilers, but when compiled with modern C++, things are more strict; thus, if you want the code to be really fine, you must avoid such warnings.
@JonatanAntoni, I strongly agree this needs to be fixed. Any code in CMSIS that introduces warnings when -Wall is enabled must not be allowed.
At the very least, a pragma needs to be added to disable the -Wnested-externs warning for that section of code.
Hi @flit,
Sure, we discussed last time if we should add these pragmas. I think this can be done.
Reworking the code would need to be done very carefully not to break anything else. Unfortunately, warning free code is no guarantee for correct code. Nor is the other way around always true. Especially in low level code you cannot always prevent all pedantic warnings while writing efficient code. Hence one needs to assess the warning in detail. In this case the warning points out that the code might not be portable. As this is code which is specific to GCC it doesn't need to be portable.
I'd suggest to consider CMSIS headers like all other system header files. Compilers typically suppress pedantic warnings on these.
Cheers, Jonatan
I'd suggest to consider CMSIS headers like all other system header files.
That's exactly what I'm doing; I'm including tons of system headers in my C++ projects and I do not get any warnings.
Similarly, I am including the CMSIS headers into the same projects, and the builds fail.
I reported the issue and I've been told that the CMSIS headers are absolutely perfect and I'm not using them correctly.
If this is the case, you can close the ticket, since we'll not get anywhere.
Compilers typically suppress pedantic warnings on these.
Do you mean that the responsibility for suppressing the warnings related to the CMSIS headers is not yours but of the compilers?
I guess you can try to arrange with the GCC team and the clang team to patch their compilers to accommodate your desire, but I doubt they'll consider this seriously.
With or without pragmas, professionally written libraries should never break builds.
For various reasons, my builds are configured with all warnings enabled and -Werror; integrating the CMSIS headers always was a big challenge, since they do not meet the minimum quality requirement of not breaking the builds.
As @sgauche mentioned in the previous link, it seems ST is also affected by this issue, and their workaround was to stick to CMSIS 5.4.0. :-(
Sooner or later Arm has to address this, the current code is not ok.
@ilg-ul, please provide a PR fixing this issue for your case. I.e. by adding the required pragma like #pragma GCC diagnostic ignored "-Wnested-externs". Thanks.
@sgauche, could you also suggest a solution to make your builds pass with the latest CMSIS?
In my opinion silencing the warning for GCC is not the right solution, since tomorrow we might want to compile this with another compiler, especially in a C++ project , and the problem will re-surface.
The problem here is that although extern definitions in the scope of a function are not strictly illegal in legacy C, they are discouraged in modern C and especially in C++, thus the warnings.
My current workaround was to define __PROGRAM_START and so the entire code is skipped, and the warning is no longer triggered. But this is a kludge.
My current workaround was to define __PROGRAM_START and so the entire code is skipped, and the warning is no longer triggered. But this a kludge.
If you guys think the code is not required we can remove it.
I don't want to speak for the entire community, but in my projects I use a more elaborate startup anyway, so this code is of no use for me. But the implementation is not fortunate anyway.
However I think that the idea of a generic mechanism to initialize multiple BSS and DATA areas is valuable, I also use a similar mechanism in my startup, so perhaps this idea should be further refined.