26 Apr
2016
26 Apr
'16
5:27 p.m.
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(a)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
26 Apr
26 Apr
5:58 p.m.
New subject: memmove() is failing on MIPS CPU
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
8:04 p.m.
New subject: memmove() is failing on MIPS CPU
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(a)microsemi.com>
Cc: Lance Fredrickson <lancethepants(a)gmail.com>om>; Waldemar Brodkorb
<wbx(a)uclibc-ng.org>rg>; devel(a)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
28 Apr
28 Apr
8:21 p.m.
New subject: memmove() is failing on MIPS CPU
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
29 Apr
29 Apr
6:28 a.m.
New subject: memmove() is failing on MIPS CPU
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(a)microsemi.com>
Cc: Waldemar Brodkorb <wbx(a)uclibc-ng.org>rg>; Lance Fredrickson
<lancethepants(a)gmail.com>om>; devel(a)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
2916
days inactive
2919
days old
4 comments
2 participants
participants (2)
-
Rene Nielsen -
Waldemar Brodkorb