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

Rene Nielsen rene.nielsen at microsemi.com
Tue Apr 26 22:04:43 CEST 2016


I took a closer look at .../libc/string/mips/memcpy.S since that's the one that gets called with the unpatched memmove.c.
It could be, I thought, that memcpy() is supposed to have support for overlapping regions, but then I came across this section:

/*
 * Below we handle the case where memcpy is called with overlapping src and dst.
 * Although memcpy is not required to handle this case, some parts of Android
 * like Skia rely on such usage. We call memmove to handle such cases.
 */
#ifdef USE_MEMMOVE_FOR_OVERLAP
        PTR_SUBU t0,a0,a1
        PTR_SRA t2,t0,31
        xor     t1,t0,t2
        PTR_SUBU t0,t1,t2
        sltu    t2,t0,a2
        beq     t2,zero,L(memcpy)
        la      t9,memmove
        jr      t9
         nop
L(memcpy):
#endif

Since memcpy() may resort to calling memmove() for overlapping regions, I could imagine that it doesn't have support for it, which in turn tells me that memmove() is not supposed to ever call memcpy() on MIPS CPUs.

USE_MEMMOVE_FOR_OVERLAP is not defined on our platform, so [luckily?] we won't get into an endless loop of alternating calls to memmove() and memcpy() [if we did, we might have found the problem sooner].

Anyway, would it be possible to find out whether Qemu uses the same #defines (especially whether __ARCH_HAS_BWD_MEMCPY__ is defined or not)? (I'm sorry, but I have absolutely no idea how to compile for Qemu, since I'm not our SDK-master, just a simple user).

Thanks in advance,
René

-----Original Message-----
From: Waldemar Brodkorb [mailto:wbx at uclibc-ng.org] 
Sent: 26. april 2016 19:59
To: Rene Nielsen <rene.nielsen at microsemi.com>
Cc: Lance Fredrickson <lancethepants at gmail.com>; Waldemar Brodkorb <wbx at uclibc-ng.org>; devel at uclibc-ng.org
Subject: Re: [uclibc-ng-devel] memmove() is failing on MIPS CPU

EXTERNAL EMAIL


Hi Rene,
Rene Nielsen wrote,

> Thanks, Lance, for backing me up here and for shedding further light on the issue.
>
> I wondered why Waldemar is asking so much about use of floating point, so I double-checked the kernel. It is indeed compiled with "CONFIG_CPU_R4K_FPU=y", but during boot it will figure out that there's no H/W FPU support on the actual CPU and therefore not push/pop FPU regs during task switches.
>
> How it resorts to doing soft-float is not crystal clear to me.

If your toolchain is configured for soft-float, no FPU is used on the target, even if the hardware has a FPU.
If your toolchain is configured for hard-float, it will even use FPU code, as the unmodified upstream Kernel always have FPU emulation code activated on MIPS.

I think OpenWrt patched out the FPU emulation code in the kernel and use soft-float toolchain by default to save some bytes in the resulting firmware. I did'nt checked recently if this is still the case.

> I looked at the changeset you mentioned, Waldemar (2636b17616a19d628c3dbc373ebae67ef6e2b1f6), to get an idea why you are so keen to know about floating point.

Let's say it is just one of the things I want to have matched, as I couldn't reproduce any of the reported issues in the past about this bug. We had no crystal clear testcase which showed the problem in the past.
There were issues with openvpn and some torrent software. I tested the torrent software on my RB532 MIPS32 board and couldn't reproduce it there.

The code which is imported seems to work fine for newlib and GNU libc people. So I am wondering if it is some issue around the code in uClibc or if it wasn't tested on real equipment or older kernels so much.

But that's all guessing.

I will retest on my RB532 soon. I surely a fan of testing on real hardware, but most of the time issues are reproducable in Qemu System Emulation.

> Then I modified .../libc/string/mips/memcpy.S to see which macros were defined and which were not. I got to this conclusion:
>   ANDROID_CHANGES undefined
>   _LIBC defined
>   _MIPS_ISA_MIPS32 defined
>   DISABLE_PREFETCH undefined, so USE_PREFETCH gets defined
>   _MIPS_SIM undefined

I am wondering if this is a problem, or if it is only used for MIPS64 to distinguish between N32/N64/O32 ABI.

best regards
 Waldemar


More information about the devel mailing list