On Thu, 20 May 2021 at 05:25, Marek Behún <marek.be...@nic.cz> wrote: > > It seems that sometimes (happening on ARM64, for example with > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol > names of some functions, for example lib/string.c's memcpy() function to > memcpy.isra.0. > > This is a problem however when GCC for a code such as this: > struct some_struct *info = get_some_struct(); > struct some struct tmpinfo; > tmpinfo = *info; > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo. > > This then results in the following linking error: > .../lz4.c:93: undefined reference to `memcpy' > .../uuid.c:206: more undefined references to `memcpy' follow > > GCC's documentation says this about -nodefaultlibs option: > The compiler may generate calls to "memcmp", "memset", "memcpy" and > "memmove". These entries are usually resolved by entries in libc. > These entry points should be supplied through some other mechanism > when this option is specified. > > Make these functions visible by using the __used macro to avoid this > error. > > Signed-off-by: Marek Behún <marek.be...@nic.cz> > --- > lib/string.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass <s...@chromium.org>
