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.
Update : 'freestanding' won't work as a workaround because "GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp" so I definitely need to find the correct library.
memcpy
memmove
memset
memcmp" so I definitely need to find the correct library.
I found this article online discussing use of various GCC libraries. Does this help you?
https://metebalci.com/blog/demystifying-arm-gnu-toolchain-specs-nano-and-nosys/
Thanks for the response. This indicates that libraries are precompiled with various options and it seems to confirm that an appropriate one is indeed libc_nano. However, there are many instances of this (I found 38) in the toolchain directory structure I could guess the right file is somewhere in /thumb (I'd rather not)... but I can't find any documentation about the various subdirectories (v7-m, v7e-m etc) and what differentiates them.
Hi Neil,You don't have to select the correct library for your target: the compiler does this for you. If (as is described in the link Ronan sent), you use the `gcc` (in our case: arm-none-eabi-gcc) binary to invoke the link step. Also make sure you use your -march/-mcpu options for your target.If that isn't happening, could you share your command line options to the link step? You may have something there that stops the library from beuing used (such as -nostdlib).In terms of specs files:* The base newlibis the default, if you have no specs option* For newlib-nano, the library optimized for smallest size, add -specs=nano.specsThen, depending on the completeness of your program, you may also need to add -specs=nosys.specs. This provides stub definitions for some functions that are needed when running on real hardware.
This is a link-time error. The compile ($ /applications/ArmGNUToolchain/13.2.Rel1/arm-none-eabi/bin/arm-none-eabi-gcc) completes OK but has (unresolved) references to memcpy etc which need to be resolved at link time. The compiler invocation options are -Wall -fno-common -mcpu=cortex-m7 -mthumb -O2 -c -g -Wa,-adlhs
I'm expecting to have to include a specified library in the linker invocation : something like -L"/usr/lib/... file.a" but don't know which one to specify.
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 )