> -----Original Message----- > From: Richard Earnshaw (lists) <Richard.Earnshaw@xxxxxxx> > Sent: 17 April 2025 14:57 > To: Wasim Khan <wasim.khan@xxxxxxx>; gcc-help@xxxxxxxxxxx; > gcc@xxxxxxxxxxx > Subject: Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64- > none-elf > > [You don't often get email from richard.earnshaw@xxxxxxx. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On 17/04/2025 07:49, Wasim Khan via Gcc wrote: > > Hi, > > > > I have a custom implementation of memcpy() function and don't want to use > implementation provided by libc.a. > > Things works fine with toolchain version 12.3 and my local implementation in > utils.c is considered. > > But when I move to toolchain version 14.2 , I am getting below error. > > > > > > Linking ... > > /opt/arm-gnu-toolchain-*-aarch64-none-elf/bin/aarch64-none-elf-gcc \ > > -nodefaultlibs \ > > -nostartfiles \ > > -mcpu=cortex-a55 \ > > -Wl,--gc-sections \ > > -Wl,--build-id=none \ > > -T /opt/test.lds \ > > -Wl,-Map=/opt/test.map \ > > -Wl,--no-warn-rwx-segments \ > > /opt/test.o /opt/utils.o \ > > -L /opt/arm-gnu-toolchain-*-aarch64-none-elf/aarch64-none-elf/lib \ > > -Wl,--start-group -l:libc.a -l:libgcc.a -Wl,--end-group \ > > -o /opt/test.elf > > > > /opt/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none- > elf/bin/../lib/gcc/aarch64-none-elf/14.2.1/../../../../aarch64-none-elf/bin/ld: > /opt/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-elf/aarch64-none- > elf/lib/libc.a(libc_a-memcpy.o): in function `memcpy': > > /data/jenkins/workspace/GNU-toolchain/arm-14/src/newlib- > cygwin/newlib/libc/machine/aarch64/memcpy.S:60: multiple definition of > `memcpy'; /opt/utils.o:/opt/utils.c:247: first defined here > > collect2: error: ld returned 1 exit status > > make: *** [Makefile:282: linkobj] Error 1 > > > > > > > > Need help on how to use custom implementation of memcpy() (but use all > other standard functions from libc.a). > > Also, any idea on why the issue is with 14.2 and not with earlier versions (like > 12.3) ? > > > > Regards, > > > > Perhaps your code is calling memmove() as well? The two functions are > generally tightly integrated in the C library, especially when memmove() is > assuming particular properties of the memcpy implementation. > > For example, you can't override free without also overriding all the other > functions that go with heap management (malloc, realloc, etc). > > BTW, if you generate a linker map, it should tell you why the libc implementation > of memcpy is being pulled in as well. > > R. I am not using memove() anywhere in my code. However, defining custom memove() solves the problem with 14.2. Thanks!! I wonder why it is not required with 12.3 , because as per linker map, memcpy() is coming from my custom implementation and memmove() is coming from libc for 12.3. .text.memcpy 0x000000002048d1d0 0x20 /opt/test.o 0x000000002048d1d0 memcpy .text 0x000000002049b240 0xac /opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-elf/aarch64-none-elf/lib/libc.a(libc_a-memmove.o) 0x000000002049b240 memmove This dependency is something introduced after 12.3 ? Also, is there any way to know about such dependencies of such functions? Because compiler does not complaints if custom definitions are ignored .
