> Two things could be going wrong - the cross GCC isn't outputing values
> in a form that the vax assembler expects.  The vax cross assembler isn't
> correctly parsing valid input.  All of the above...

I've already determined by inspecting assembly files that the float literals
in the Cross GCC .s file are wrong. Instead of $0d1.0000000000000E0 for 1.0,
you get something screwy like $0d1.48219467329642E-310 that cannot be found
in the original source file. Native GCC gets them right of course.

BTW I'm not using a vax cross assembler here. I'm replacing cc1 with a script
that juggles its arguments and input/output files, and then hands off to:

	ssh -c none fastmachine cross-cc1/vax/cc1

(I will be moving away from ssh soon due to other problems not related to the
compiler; I use the same technique to put nroff/gzip on a faster machine.)

> > There is an option somewhere in gcc called "SOFT_FLOAT" or something; that
> > makes gcc avoid storing floating point numbers as floats and instead
> > stores them in some other way (strings?). It is neccessary to set this
> > when a cross-compiler environment for vax is used.
> 
> Did you mean the software implementation (approximation?) of IEEE 754
> 32/64 or how GCC either write raw HEX or natural floating point values
> into the assembler file.

I have no idea; I've been trying to find this option in the gnu sources that
come with the NetBSD 1.4.x releases, with no luck so far. I'm doing a VPATH
configure of the src/gnu/dist tree that's provided with NetBSD, and only
making cc1, which I then run directly for each remote job. This technique has
been found to work well for m68k and sparc targets. (The NetBSD 19991223-sun3
snapshot was built with it.)

I believe that all I need is a way to get GCC to make no assumptions about
the host float format. Right now it really looks as if some part of the vax
cross-cc1 is assuming host floats are vax format, on an i386 host (bzzt!).

So far I haven't seen any evidence that anything else is wrong; I can build
and boot GENERIC kernels with the vax cross-cc1 setup. But once I start
building and updating new shared libraries, all hell breaks loose when (say)
inetd picks up the new libc and coredumps.

Todd Whitesel
toddpw @ best.com