We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm using the ARM GNU toolchain 13.2 rel 1. At higher levels of optimisation the compiler emits calls to memcpy, memset etc. which I cannot resolve.
These routines are not provided by the runtime environment (this is a bare-metal embedded system). However, I presume they're present in a (target dependent) library somewhere in this toolchain. For example, there are many instances of libc_nano.a (and others) but I can't work out which (if any) to use. My target is an iMXRT1062 which has a Cortex-M7 core, but I would like a generalised way to establish the correct library to link with.
I guess there's a compiler option which prevents it from emitting these calls in the first place ( is it 'freestanding'?), but I assume this would result in less efficient code.
So the general recommendation is to use the arm-none-eabi-gcc driver program to invoke the linking step. It knows where the libraries are placed and will figure out the correct library for you to use based on your command-line options.This means that if you use the arm-none-eabi-gcc binary for the linking step as: `arm-none-eabi-gcc -mcpu/-march <.o files>`, then the correct library will be pulled in automatically :)
Up until now I've been using gnu make to generate the target image. The makefile invokes the linker (/... arm-none-eabi-ld) directly and passes multiple parameters and also points to a link script (which includes memory map, section / symbol definitions etc). Just invoking gcc in place of ld throws errors. Are you recommending I rewrite the makefile to invoke gcc instead of ld and then try to resolve these errors? or is there an option I can give ld directly to identify the correct library to use? (I have read https://gcc.gnu.org/onlinedocs/gcc-12.3.0/gcc/Link-Options.html )