[BUG] Build error with GCC10 in mux.c: missing memmove, memset and memcpy

[xiulipan]

Describe the bug
After #3848 merged, when build SOF with latest GCC10 binary, got below error on all cavs platform

/home/sof/work/xtensa-apl-elf/lib/gcc/xtensa-apl-elf/10.2.0/../../../../xtensa-apl-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mux/mux.c.o: in function `mux_prepare':
/home/sof/work/sof.git/src/audio/mux/mux.c:657: undefined reference to `memmove'
/home/sof/work/xtensa-apl-elf/lib/gcc/xtensa-apl-elf/10.2.0/../../../../xtensa-apl-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mux/mux.c.o: in function `mux_mix_check':
/home/sof/work/sof.git/src/audio/mux/mux.c:62: undefined reference to `memmove'

To Reproduce

# get the latest Docker image with GCC 10
docker pull thesofproject/sof:20210228
docker tag thesofproject/sof:20210228 sof
# build with docker image in sof repo folder
./scripts/docker-run.sh ./scripts/xtensa-build-all.sh apl

Reproduction Rate
10/10

Expected behavior
Build pass without error

Impact
GCC10 docker image could not be used in CI

[xiulipan]

@fredoh9 @lgirdwood I am not sure if this is GCC compiler issue, SOF code issue or Docker build issue. Will try to reproduce with local GCC compiler.

[lgirdwood]

@xiulipan it looks like we are assigning a > 32bit variable and hence GCC will try and call the C library. Quickest way to solve is to define memmove()

[fredoh9]

@lgirdwood do we need to add memmove.S like memcopy.S (src/arch/xtensa/hal/memcopy.S). Do you have one?
or can we add memcopy.c from open source implementation?

[fredoh9]

After resolving memmove error, now linker complains memset().

/home/sof/work/xtensa-apl-elf/lib/gcc/xtensa-apl-elf/10.2.0/../../../../xtensa-apl-elf/bin/ld: CMakeFiles/bootloader.dir/__/__/platform/intel/cavs/boot_loader.c.o: in function `strcmp':
/home/sof/work/sof.git/src/platform/intel/cavs/boot_loader.c:206: undefined reference to `memset'
/home/sof/work/xtensa-apl-elf/lib/gcc/xtensa-apl-elf/10.2.0/../../../../xtensa-apl-elf/bin/ld: CMakeFiles/bootloader.dir/__/__/platform/intel/cavs/boot_loader.c.o: in function `bbzero':
/home/sof/work/sof.git/src/platform/intel/cavs/boot_loader.c:79: undefined reference to `memset'

[fredoh9]

After resolving memset(), now I'm able to build build_apl_gcc/sof-apl.ri. And I tried with byt cnl icl jsl tgl tgl-h, all are working fine. So it looks memmove() and memset() are only the problem.

@lgirdwood I made a quick workaround on src/audio/mux/mux.c and src/platform/intel/cavs/boot_loader.c respectively. I copied the function from gcc library below.
I'm not sure where I should put those functions properly. Could you advise me?

https://github.com/gcc-mirror/gcc/blob/master/libgcc/

[lgirdwood]

@fredoh9 you cant copy due to license, can you re-implement both functions and add them. Look at existing memcopy_s for guidance. Thanks

[marc-hb]

Interesting, when compiling with gcc8 -O3 I noticed this:

[ 98%] Linking C executable bootloader
CMakeFiles/bootloader.dir/__/__/platform/intel/cavs/boot_loader.c.o: In function `strcmp':
boot_loader.c:(.text+0x58): undefined reference to `memset'
CMakeFiles/bootloader.dir/__/__/platform/intel/cavs/boot_loader.c.o: In function `boot_primary_core':
boot_loader.c:(.text+0x1df): undefined reference to `memset'
collect2: error: ld returned 1 exit status

[fredoh9]

GCC8 also have same problem? I didn't notice. Let me try with GCC8 local setup.

[marc-hb]

only when you manually hardcode -O3 in CMake

[lgirdwood]

GCC8 also have same problem? I didn't notice. Let me try with GCC8 local setup.

Not worth wasting time with GCC -O3 (xtensa optimisation bugs)

[marc-hb]

There's no optimization bug with xtensa-gcc 8.1, it is rather almost as you said:

@xiulipan it looks like we are assigning a > 32bit variable and hence GCC will try and call the C library.

The source location is wrong but the rest of the error message makes sense and the behavior is documented. By trial and error I isolated the missing memset issue to bbzero() (maybe -g3 + disassembly would have been faster?[*]). This one character patch is enough to fix avoid the memset error with both gcc8.1 -O3 and gcc9.2 -O3:

--- a/src/platform/intel/cavs/boot_loader.c
+++ b/src/platform/intel/cavs/boot_loader.c
@@ -73,7 +73,7 @@ static inline void bbzero(void *dest, size_t bytes)
 	int i;
 
 	for (i = 0; i < (bytes >> 2); i++)
-		d[i] = 0;
+		d[i] = 1;
 
 	dcache_writeback_region(dest, bytes);
 }

@fredoh9 can you test this one character change with gcc10? Of course this is not a fix but just a demonstration of the issue which is: even in freestanding mode (no libc) gcc feels free to optimize code into a memset or into a memcpy

Some references:

• http://cs107e.github.io/guides/gcc/

It maybe a bit surprising to learn that even when compiling in freestanding mode, gcc can emit a call to memcpy or memset

• https://gcc.gnu.org/onlinedocs/gcc/Standards.html

Most of the compiler support routines used by GCC are present in libgcc, but there are a few exceptions. GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp.

• https://stackoverflow.com/questions/6410595/getting-gcc-to-compile-without-inserting-call-to-memcpy

• Same issue with clang: https://www.raspberrypi.org/forums/viewtopic.php?t=219687

• https://stackoverflow.com/questions/48676760/how-to-prevent-auto-optimization-from-for-loop-to-memset-in-visual-studio

[*] EDIT: no, objdump --source can barely make sense of heavily optimized code.