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

Waldemar Brodkorb wbx at uclibc-ng.org
Tue Apr 26 19:58:56 CEST 2016


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