The latest version (1.54) of RKit-ARM includes GCC for ARM version 4.8.3.
We highly recommend using this new version which includes important fixes and improvements.
However, porting old projects to this version requires care. Here are the related hints, tricks, problems, workarounds, etc. that we have found (this will evolve in the future, as we add information).
The new GCC includes newlib-nano libraries, which we recommend you use instead of newlib because:
- Some newlib functions (malloc) are much bigger.
- newlib-nano provides embedded system-specific optimizations similar to small_printf, but not only for printf (malloc, and others).
- Sticking to newlib might result in significantly larger code than with the previous version.
- Some things go in .data.something (previously .data) (same for .bss / .bss.something).
You must handle .bss.*, .data.*, .rodata.* in linker script (and of course .text.* , as with previous version of GCC).
The default linker scripts provided with Ride have been modified accordingly. You only need to modify your script if your project uses a custom linker script. - Calculations in linker script are suspect: sometimes (a+b-c)!=(a+(b-c)) . Add parentheses if in doubt or if you get link errors ("FLASH is full", ...).
The default linker scripts provided with Ride have been modified accordingly. You only need to modify your script if your project uses a custom linker script.
- The "main" symbol goes by default in section .text.startup.main (previously .text.main). For some projects you might need to modify the linker script (if main function needs to be explicitly placed).
malloc
- malloc default page size must now be defined by malloc_getpagesize_P . You can use the new linker option in Ride for that.
- malloc can now take _sbrk from libnosys instead of std_sbrk. Prefer libnosys for better compatibility with future versions of GCC.
LTO
- The new GCC provides the LTO (Link-Time Optimization) feature.
This new option produces much more compact code, much faster.
However, using it successfully on an old project is often tricky. We recommend to use it only for new projects, or to be prepared to spend a significant amount of time porting your projects to LTO.
LTO activation should be performed separately, after porting the old projects to the new GCC.
By default the LTO options are not active in Ride.
Error management
Some source code errors were tolerated by the old compiler/assembler but are rejected by the new one.
You need to correct these errors.
Some old versions of standard libraries (from ARM/ST/...) do include such cases. You should take the latest versions of these libraries from their original provider. They were corrected a long time ago.
The most common cause of these problems is bad use of strexh and strexb during (usually not linked) inline assembly in file core_cm3.c, which is part of ARM's CMSIS libraries and included in ST peripheral libraries.
You have two ways to solve this. Both ways are valid and you can choose one or the other depending on your situation:
1. Update all libraries (CMSIS, peripheral libraries, etc.). This is the cleaner way, and best for the long term, but if you were using a very old version of the libraries, that might require a lot of work in the short term to adapt your code that calls the libraries.
2. Edit core_cm3.c and comment out the definitions of functions __STREXH and __STREXB. These functions, which hold the problem, are very rarely used and it is highly likely that your application doesn't need them. If you do use them, then you should update the libraries (option 1 above).
Optimization
The new version of the compiler optimizes code much more than the previous version.
This can lead to problems when the code contains errors that did not create operational problems with less aggressive optimization.
This is true whenever you update a compiler, not only for this version.
You can find more details here: http://support.raisonance.com/content/why-did-my-project-stop-working-after-updating-compiler