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.
I looked at the changeset you mentioned, Waldemar (2636b17616a19d628c3dbc373ebae67ef6e2b1f6), to get an idea why you are so keen to know about floating point.
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 USE_DOUBLE remains undefined L defined PTR_ADDIU defined PTR_SRA defined PTR_LSA undefined, but gets defined to lsa
Hope it points in the right direction.
Thanks, René
-----Original Message----- From: Lance Fredrickson [mailto:lancethepants@gmail.com] Sent: 26. april 2016 16:18 To: Rene Nielsen rene.nielsen@microsemi.com Subject: Re: [uclibc-ng-devel] memmove() is failing on MIPS CPU
I've also experienced the same issues described by Rene. Up until now I've been applying the patches that entware-ng/optware-ng use which revert the mipsel changes between 1.0.9 and 1.0.10.
Without Rene's patch, or reverting those mipsel commits, Rene's test.c fails to run, and experiences same error's he experiences. With his patch it is working as expected.
Note: with or without patching, the static "test" binary I make works with qemu on x64_86 machine. It's only when I run it on the actual mipsel hardware that it fails. So testing with qemu for whatever reason is not an indication in this case of how it will work on the actual hardware.
kernel 2.6.22.19 binutils 2.25.1 gcc 5.3.0 mips32 soft-float
I'm working with routers like entware-ng/optware-ng, so am also stuck on the same kernel they are. I know entware-ng is using cross-tools-ng for their toolchain. I am using buildroot for mine.
thanks, Lance
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
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@uclibc-ng.org] Sent: 26. april 2016 19:59 To: Rene Nielsen rene.nielsen@microsemi.com Cc: Lance Fredrickson lancethepants@gmail.com; Waldemar Brodkorb wbx@uclibc-ng.org; devel@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
Hi Rene, Rene Nielsen wrote,
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:
Can you send me the uClibc config you use. Don't know why I haven't thought about that, yet.
Still can't reproduce it with OpenADK, so may be my config is just better ;)
best regards Waldemar
Hi Waldemar,
My bad. I should've added uClibc's .config file in the first place. Here you go (had to rename it to be able to attach it).
BR, René
-----Original Message----- From: Waldemar Brodkorb [mailto:wbx@uclibc-ng.org] Sent: 28. april 2016 22:22 To: Rene Nielsen rene.nielsen@microsemi.com Cc: Waldemar Brodkorb wbx@uclibc-ng.org; Lance Fredrickson lancethepants@gmail.com; devel@uclibc-ng.org Subject: Re: [uclibc-ng-devel] memmove() is failing on MIPS CPU
EXTERNAL EMAIL
Hi Rene, Rene Nielsen wrote,
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:
Can you send me the uClibc config you use. Don't know why I haven't thought about that, yet.
Still can't reproduce it with OpenADK, so may be my config is just better ;)
best regards Waldemar
-
Rene Nielsen -
Waldemar Brodkorb