I'd accidentally built libc without SOFTFLOAT defined, so setjmp() was
> trying to save the floating-point registers.  Oops.
> 

Which actually brings up what might be an important question.  The current 
SOFTFLOAT code on the ARM uses the rather bizzare FPA endianess for the 
words of a double when stored in memory -- this

1) causes no-end of packages to fail to operate correctly on ARMs because 
they assume either a pure little-endian double on a little-endian machine 
or a pure big-endian double on a big endian machine
2) For little-endian machines (as all NetBSD/arm ports currently are) this 
is the opposite way around to the way the VFP does it.

It seems likely to me that no new ARM processors will ever be designed 
with the old FPA interface (it isn't even mentioned in the ARM ARM, and as 
one colleague put it - the FPA is dead and the soner it goes away the 
better).  Even with existing processors, only the ARM7500FE has been 
shipped with an FPA in significant numbers, and on netbsd we still don't 
make a use of it.

So, to the question.  If I knock up a hack to the compiler and assembler 
so that for NetBSD/ARM/ELF they change to a pure little-endian floating 
point format, would there be any objections?

A small number of packages that have already been fixed to work on the ARM 
may need re-fixing (those that don't use auto-conf type techniques and 
have to be hard-coded with a #define somewhere), but I do think this 
should be the way forward.

I haven't tested it, but I believe the patch to the compiler is trivial.  
In the arm/netbsd/elf header file, after including arm.h (probably 
indirectly), we simply add

#undef FLOAT_WORDS_BIG_ENDIAN

We would probably also want to add __SOFT_FP_VFP__ as a define to the CPP 
flags, so that apps can tell that the application works the "new" way.

For the assembler, for the rare cases where assembly language contains 
.double (gcc never generates this), we just have to change the following 
loop in md_atof() so that it spits out the `words' in the order 3210:

  else
    {
      /* For a 4 byte float the order of elements in `words' is 1 0.  For 
an
         8 byte float the order is 1 0 3 2.  */
      for (i = 0; i < prec; i += 2)
        {
          md_number_to_chars (litP, (valueT) words[i + 1], 2);
          md_number_to_chars (litP + 2, (valueT) words[i], 2);
          litP += 4;
        }
    }


Comments, flames, rounds of manical laughter?