[uclibc-ng-devel] memmove() is failing on MIPS CPU

Waldemar Brodkorb wbx at uclibc-ng.org
Thu Apr 21 20:34:05 CEST 2016


Hi Rene,
Rene Nielsen wrote,

> I have found a bug in .../libc/string/generic/memmove.c, which is the one that
> MIPS uses, since there's no specialized, optimized version for MIPS.
> 
> We're currently using uClibc v. 1.0.12, but I suspect the bug to be present in
> earlier releases too.
> 
> Here's a snippet from memmove.c#memmove():
> ---------------------oOo---------------------
>   /* This test makes the forward copying code be used whenever possible.
>      Reduces the working set.  */
>   if (dstp - srcp >= len)       /* *Unsigned* compare!  */
>     {
> #ifndef __ARCH_HAS_BWD_MEMCPY__
>       /* Backward memcpy implementation cannot be used */
>       memcpy(dest, src, len);
> #else
>       /* Copy from the beginning to the end.  */
> ---------------------oOo---------------------
> 
> Given the name of the define (__ARCH_HAS_BWD_MEMCPY__) it sounds as when this is
> defined, the architecture indeed has backward memcpy() support. But how come the
> line is preceded by #ifndef and not #ifdef, when the code inside calls memcpy()?
> 
> Also, the first comment inside the #ifndef seems odd, since memcpy() indeed is called:
>   /* Backward memcpy implementation cannot be used */
> 
> Our SDK does not define __ARCH_HAS_BWD_MEMCPY__, so when memmove()
> resorts to a simple memcpy() that does the wrong thing for overlapping regions,
> our application fails with disastrous side-effects.
> 
> I have attached a patch that fixes this.
> 
> Please CC me in case of any inquiries/replies: rene.nielsen (at) microsemi.com

You are right, there is no special MIPS version for memmove().
The __ARCH_HAS_BWD_MEMCPY__ symbols was added in 2008 by this
commit e4f55f33f69fce85099dd5936cc74856aa1b453d. I would rather say,
that a default memcpy is used and there was a change for MIPS
recently.
Can you either try 1.0.9 or revert
2636b17616a19d628c3dbc373ebae67ef6e2b1f6 from 1.0.14?

The change to add MIPSr6 support ported from glibc and submitted by
Steve Ellcey <sellcey at imgtec.com> seems to trigger a problem with
old kernels on MIPS32 systems. If you search the mailinglist we had
some reports in the past, but I still couldn't reproduce the issue
to report to Steve.

Can you create a small test program showing your problem?
Something for the included test-suite would be really great.

What MIPS system do you use? MIPS32r2? little or big endian?
hard or soft-float toolchain? Which kernel version?

thanks
 Waldemar


More information about the devel mailing list