On 17/04/2025 12:19, Wasim Khan via Gcc wrote:
>
>
>> -----Original Message-----
>> From: Richard Earnshaw (lists) <richard.earns...@arm.com>
>> Sent: 17 April 2025 14:57
>> To: Wasim Khan <wasim.k...@nxp.com>; gcc-h...@gcc.gnu.org;
>> gcc@gcc.gnu.org
>> Subject: Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-
>> none-elf
>>
>> [You don't often get email from richard.earns...@arm.com. 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 .
>
>
Compilers can generate code where they know a memcpy or memmove operation are
needed without the direct need for an explicit call to that function (memcpy is
more common, since the compiler can usually be sure that the objects being
copied do not overlap). But of course, it might come from a library function
that needs this as well.
The linker map will tell you which object file contains the first reference to
memmove and hence why it is adding libc_a-memmove.o to the image; it won't tell
you of all the cases though.
You need to look at the section of the map file that begins something like:
Archive member included to satisfy reference by file (symbol)
/usr/lib/x86_64-linux-gnu/libm-2.35.a(w_sqrt.o)
/tmp/ccPpkxxR.o (sqrt)
/usr/lib/x86_64-linux-gnu/libm-2.35.a(e_sqrt.o)
/usr/lib/x86_64-linux-gnu/libm-2.35.a(w_sqrt.o)
(__ieee754_sqrt)
...
The syntax of each entry is
<archive>(<member-file>) <referencing-file>(<symbol>)
R.
