[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))



On 5/7/10, Luca Niccoli <lultimouomo@gmail.com> wrote:
> On 7 May 2010 10:58, Thibaut Paumard <mlotpot.news@free.fr> 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


Reply to: