Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
Le 10 mai 10 à 14:48, Thibaut Paumard a écrit :
Contrary to my guess, the SIGILL is not triggered by
feenableexcept() but by setjmp().
The bug is [1]known and is fixed in libc6 2.11 currently in
experimental.
[1] http://old.nabble.com/ARM-EABI-setjmp-longjmp-fixes-
td26015953.html
For your information, the bug is now corrected in unstable:
Changes:
eglibc (2.10.2-8) unstable; urgency=low
.
[...]
* Add patches/arm/cvs-setjmp-longjmp-fpu.diff. closes: #580529
("setjmp/longjmp broken on ARM w/ FPU").
Regards, Thibaut.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/f6961500-faf9-40d8-afba-aa86174e2...@users.sourceforge.net
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 580529 "setjmp/longjmp broken on ARM w/ FPU" reassign 580529 libc6 2.10.2 fixed 580529 2.11 thanks Le 9 mai 10 à 15:37, Martin Michlmayr a écrit : * Thibaut Paumard [2010-05-09 15:19]: I attach a short test-case which I have used already to demonstrate buggy SIGFPE handling on another arch. Usage is documented in the file. Can you check whether this test case: On Thecus N2100 (using an IOP32x CPU): (sid eabi)1587:t...@all6500: ~/src] ./fputest iffi Triggering integer SIGFPE: 1/0=(SIGFPE trapped)0 Triggering floating SIGFPE: 1./0.=Triggering floating SIGFPE: 1./0.=Triggering integer SIGFPE: 1/0=(SIGFPE trapped)0 On the Marvell DB-78x00-BP Development Board: (sid)t...@mv78x00:~/src$ ./fputest iffi Illegal instruction Contrary to my guess, the SIGILL is not triggered by feenableexcept() but by setjmp(). The bug is [1]known and is fixed in libc6 2.11 currently in experimental. [1] http://old.nabble.com/ARM-EABI-setjmp-longjmp-fixes-td26015953.html I just cannot work around this bug in Yorick. In the meantime, I will just have to go on requesting that Yorick and associated packages be built on other machines than ancina. Thanks to everybody from the ARM list for your help. Best regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkvoALUACgkQ+37NkUuUiPEDvACcDuWrgkxrByQ361u8fJhDH2u0 V30An3IDmB5HSjnOnRd+8kXbV1aXzUgB =NoSa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fc8fb172-e8a0-4e05-8a6d-a86038b8e...@users.sourceforge.net
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
Hi,
Le 9 mai 10 à 15:42, Martin Guy a écrit :
A quick grep in the source turns up
play/unix/fpuset.c:332
#elif defined(FPU_GCC_ARM)
void
u_fpu_setup(int when)
{
if (when <= 0) {
unsigned int fpucw = 0x70200;
__asm__ ("wfs %0" : : "r" (fpucw));
/* includes bit to trap on signalling NaN (may affect libm
behavior) */
}
}
[...]
where "wfs" is an old FPA instruction. Unfortunately, the
play/unix/config.sh chooses a GCC_FPU_* macro by testing whether this
file compiles, not whether it runs.
From the build log, FPU_GCC_FENV is selected, not FPU_GCC_ARM. I
believe it is really fpeenableexcept() from fenv.h that fails, I guess
that means a bug in either GCC or the kernel, right?
The "easy" way out is to build with "FPU_IGNORE" so yorick won't try
catching FPE's at all (I'll try that by tomorrow). This way it will
run on all machines, but with the drawback that it will die upon FPE's
instead of entering debug mode. I'm not sure whether this is better
than the current situation, where yorick runs well on most machines
and not at all on other machines.
Regards, Thibaut.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/38e3b115-4513-42e8-b909-53d0cac7d...@free.fr
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
On 5/7/10, Luca Niccoli wrote:
> On 7 May 2010 10:58, Thibaut Paumard wrote:
> > This is the info I got from Stephen Gran on d-admin:
> >
> > Processor : Feroceon rev 0 (v5l)
> $ cat /proc/cpuinfo
>
> Processor : Feroceon 88FR131 rev 1 (v5l)
>
> Processor bug that was corrected in a later revision?
A search for "Feroceon rev" turns up a different theory:
http://old.nabble.com/Re:-gcl-and-reverse-dependencies-on-arm-td27347704.html
which suggests that it may be an old-ABI kernel system call or an
unemulated FPA floating point instruction) that would not fail on
machines with standard Debian kernels, which have old-ABI emulation
and FPA emulation) enabled.
A quick grep in the source turns up
play/unix/fpuset.c:332
#elif defined(FPU_GCC_ARM)
void
u_fpu_setup(int when)
{
if (when <= 0) {
unsigned int fpucw = 0x70200;
__asm__ ("wfs %0" : : "r" (fpucw));
/* includes bit to trap on signalling NaN (may affect libm behavior) */
}
}
#elif defined(FPU_IGNORE)
void
u_fpu_setup(int when)
{
}
where "wfs" is an old FPA instruction. Unfortunately, the
play/unix/config.sh chooses a GCC_FPU_* macro by testing whether this
file compiles, not whether it runs.
The change from arm to armel (old-ABI to EABI) dropped the use of
hardfloat instructions for the FPA and switched to softfloat, also
allowing the use of VFP or Maverick FPUs if the user recompiles the
package with magic runes.
A quick hack to remove the FPA instruction and just not handle
signalling NaNs on armel is
- #elif defined(FPU_GCC_ARM)
+ #elif defined(FPU_GCC_ARM) && !defined(__VFP_FP__) && !defined(__MAVERICK__)
but a quick look at the compaint from the build log suggests that this
removes all handling of SIGFPE, including the uses that don't depend
on signalling NaNs. Maybe you have a better idea than me of what
functionality yorick really needs from the FPU exceptions and how to
find a better compromise.
See http://wiki.debian.org/ArmEabiPort#GCCpreprocessormacrosforfloatingpoint
for the non-obvious meaning of these defines (__VFP_FP__ does not mean
you have a hardware VFP FPU, it is about floating point storage
format)
Other gurus may be able to suggest alternatives that will work when
softfloat and/or VFP are selected. No one really cares about Maverick
FPUs as they are more rare - I just mention it here to get the ifdef
right.
Sadly, the fenv(3) family of functions doesn't handle the signalling
NaN exceptions, which is what yorick really needs here.
Hope that helps
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktimtrctcofniz7vhhyxna7seaqcjjev3zglpz...@mail.gmail.com
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
* Thibaut Paumard [2010-05-09 15:19]: > I attach a short test-case which I have used already to demonstrate > buggy SIGFPE handling on another arch. Usage is documented in the > file. Can you check whether this test case: On Thecus N2100 (using an IOP32x CPU): (sid eabi)1587:t...@all6500: ~/src] ./fputest iffi Triggering integer SIGFPE: 1/0=(SIGFPE trapped)0 Triggering floating SIGFPE: 1./0.=Triggering floating SIGFPE: 1./0.=Triggering integer SIGFPE: 1/0=(SIGFPE trapped)0 On the Marvell DB-78x00-BP Development Board: (sid)t...@mv78x00:~/src$ ./fputest iffi Illegal instruction -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100509133752.gt12...@jirafa.cyrius.com
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
Le 9 mai 10 à 14:03, Martin Michlmayr a écrit : * Luca Niccoli [2010-05-07 11:21]: This is the info I got from Stephen Gran on d-admin: Processor : Feroceon rev 0 (v5l) Hardware: Marvell DB-78x00-BP Development Board Processor : Feroceon 88FR131 rev 1 (v5l) Hardware: Marvell OpenRD Base Board Processor bug that was corrected in a later revision? The OpenRD uses a Kirkwood SoC while the DB-78x00-BP Development Board uses an MV78xx0 SoC. While they both use the Feroceon core, there are notable differences. For example, the Kirkwood has no FPU while the MV78xx0 has one IIRC. In any case, we have pretty good contacts at Marvell so if anyone has a testcase (ideally a smaller one than "run yorick") we can forward it to them. Hi, Porting issues with Yorick are often (always?) related to FPE trapping. Since you mention that one of those has an FPU while the other does not, the problem must lie there again, perhaps at "feenableexcept()". I attach a short test-case which I have used already to demonstrate buggy SIGFPE handling on another arch. Usage is documented in the file. Can you check whether this test case: - runs fine; - triggers SIGFPE; - triggers SIGILL? Best regards, Thibaut. fputest.c Description: Binary data
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
* Luca Niccoli [2010-05-07 11:21]: > > This is the info I got from Stephen Gran on d-admin: > > > > Processor : Feroceon rev 0 (v5l) > > Hardware: Marvell DB-78x00-BP Development Board > > Processor : Feroceon 88FR131 rev 1 (v5l) > Hardware : Marvell OpenRD Base Board > Processor bug that was corrected in a later revision? The OpenRD uses a Kirkwood SoC while the DB-78x00-BP Development Board uses an MV78xx0 SoC. While they both use the Feroceon core, there are notable differences. For example, the Kirkwood has no FPU while the MV78xx0 has one IIRC. In any case, we have pretty good contacts at Marvell so if anyone has a testcase (ideally a smaller one than "run yorick") we can forward it to them. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100509120314.gg12...@jirafa.cyrius.com
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
* Thibaut Paumard [2010-05-07 10:58]: > Hardware: Marvell DB-78x00-BP Development Board > Does anyone has a similar box to try and pinpoint the problem? > > To see whether you are affected, just install and run "yorick". If > that doesn't trigger "SIGILL", presumably you can't help me... I just tried to start yorick on another DB-78x00-BP development board and also get the SIGILL. However, I don't get the SIGILL on a Thecus N2100 (which we also use for some buildds), so a workaround would be to build yorick on another buildd. Riku Voipio should be able to give you access to the DB-78x00-BP development board. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100509115345.ge12...@jirafa.cyrius.com
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
On 7 May 2010 10:58, Thibaut Paumard wrote: > This is the info I got from Stephen Gran on d-admin: > > Processor : Feroceon rev 0 (v5l) $ cat /proc/cpuinfo Processor : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 1199.30 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: Marvell OpenRD Base Board Revision: Serial : $ yorick Copyright (c) 2005. The Regents of the University of California. All rights reserved. Yorick 2.1.05x ready. For help type 'help' > Processor bug that was corrected in a later revision? Cheers, Luca -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/w2q4e9568871005070221r734fac8cgda71e48d1cf81...@mail.gmail.com
