2025-02-20 08:44 AM
When building an STM32CubeMX generated cmake project with clang there are two files that generate errors:
sysmem.c produces the following error:
Core/Src/sysmem.c:30:35: error: use of undeclared identifier 'NULL'
[build] 30 | static uint8_t *__sbrk_heap_end = NULL;
This is caused by the fact that only errno.h and stdint.h are included. None of them officially define NULL. But they probably do in gcc.
sysmem.c can easily be modified by either:
Linker scmemory region not defined: RAM
[build] >>> _estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */ript generates the following errors:
and
[build] ld.lld: error: STM32L431RCTX_FLASH_clang.ld:93: symbol not found: READONLY
[build] ld.lld: error: unable to place section .ARM.extab at file offset [0xFFFFFFFFF8010000, 0xFFFFFFFFF800FFFF]; check your linker script for overflows
Linker script can easily be modified by:
Modifying sysmem.c would have priority in my opinion since linker scripts often need to be modified anyway.
The resulting code now builds with both clang and gcc without errors (many warnings though, but that is kind of the point for me, so I can run clang-tidy and parse the syntax tree).
2025-02-20 11:09 AM - edited 2025-02-20 11:11 AM
About NULL: +1.
Even without clang, It looks like stdint.h from "mainstream" GNU headers does not define NULL. The following causes error with gcc on rextester:
//gcc 7.4.0
#include <errno.h>
#include <stdint.h>
int main(void)
{
return (int)NULL;
}
NULL is defined in the newlib headers, not portable.
2025-02-21 06:53 AM
Hello @unsigned_char_array
The Cmake project generated by STM32CubeMX is typically designed to work with the GNU Arm Embedded Toolchain.
2025-02-21 06:57 AM
I know. But there is a bug in sysmem.c that can be fixed with 1 line of code.
2025-02-22 03:37 AM
> that can be fixed with 1 line of code.
Sorry but things are not that simple in real life. In order to make any tiny change someone has to open a ticket, fill in a bunch of data. Then it should pass code review, possibly some CI too, then someone else should approve, then build deliverables... like that.
2025-02-22 03:45 AM
I agree 100%. But this extra include shouldn't lead to other problems. If so then those are bugs too. It should be reviewed and tested and automated builds for various projects and targets should pass.Then it should be rolled out (perhaps for only part of the targets initially). If it causes problems with users it can be addressed. So it shouldn't be difficult, just take time. I don't care if it takes several months as long as it is addressed.
I see a future where GCC and Eclipse won't be the default tools anymore.