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

Rene Nielsen rene.nielsen at microsemi.com
Mon Apr 25 16:28:24 CEST 2016


Thanks for your swift reply, Waldemar!

We're using a flavor of MIPS32r2 called MIPS 24KEc. It's running little-endian with soft-floats, kernel version 3.14.

I have attached a tiny program (test.c) that fails (see fail.txt) on uClibc v. 1.0.12 without the patch I attached to my previous post.

Reverting to v. 1.0.9 also solves the problem!

Thanks,
René (rene.nielsen (at) microsemi.com)

-----Original Message-----
From: Waldemar Brodkorb [mailto:wbx at uclibc-ng.org] 
Sent: 21. april 2016 20:34
To: Rene Nielsen <rene.nielsen at microsemi.com>
Cc: devel at uclibc-ng.org
Subject: Re: [uclibc-ng-devel] memmove() is failing on MIPS CPU

EXTERNAL EMAIL


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
	 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.c
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20160425/d76fcde0/attachment-0001.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fail.txt
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20160425/d76fcde0/attachment-0001.txt>


More information about the devel mailing list