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@uclibc-ng.org]
Sent: 21. april 2016 20:34
To: Rene Nielsen <rene.nielsen(a)microsemi.com>
Cc: devel(a)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(a)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