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 )