Todd--

The right fix is that we build bi-endian toolchains for mips, so that
we can compile for mipsel on a mipseb with the "native" toolchain, and
vice-versa. so we'd always configure

	    	    mipseb-unknown-netbsd
	    	    mipsel-unknown-netbsd

on both little and big-endian mips, and select the default vector at
build time (based on the byteorder as determined by a sysctl check of
the bytorder).

The reason we don't is that FSF/Cygnus codebase still thinks that
mipsel == mips-dec-* (pmaxes are the only little-endian mips), and all
other mips are big-endian.  Once we fix that, most of the problems
you're asking about go away.


If I could, I'd configure four targets, for both 64 and 32-bit mips.
We can't, due to the way GDB uses core_addrs: it breaks libbfd.  
  [The ``right'' approach (short of "fixing" gdb our way, which Cygnus
   wont buy back) is to use a separate libbfd for gdb.  (gdb and binutils
   have always played leapfrog with the version of binutils they
   require.)  ISTR the egcs people said the same thing: they may step
   libbfd in ways that don't work for any stable gdb release.]


>Regardless of the chip involved, a little endian system and a big endian
>system are _not_ the same architecture.

Huh?  CPUs of the same chip type or family *are* of the same
architecture.  That's what computer ``architecture'' means!

>  Even ``what CPU architecture is this'' is different
>between little and big endian.

I dont think it isn't a different architecture.  They're both mips.

MIPS CPUs has an endian-ness pin which sets the endian-ness at CPU
reset time.  For mips1 (r2000), all processes use the kernel-mode
endianness.  I'm pretty sure the R6000 ECL CPU did as well.

The mips-III (r4k) and better also have a per-process userspace "this
process is other-endian" bit.  In principle we could even run mipsel
and mipseb binaries on the "same" machine.

Whatever happens with this, we have be more careful of the fact that,
before bi-endian CPUs, ${MACHINE_ARCH} (and `uname -m`) was used for
two incompatible purposes:
	1) what kind of CPU family is this chip?
	   (LE and  BE chips are the same) or IOW,
	    the ``architecture'' of the CPU chip.
	2) What endian-ness of the given CPU architecture
	   is this?
	
case 2) matters for installs (or installing packages), for configuring
the toolchain during toolchain builds.  What else?  Choosing the
default toolchain vector can be done as above.


case 1) matters for quite a few places:
     * what object format to use (elf vs. aout)
     * which programs to build and install
     * the mapping between ${MACHINE_ARCH} and  the include
       directories
     * third-party source which tests for ``mips''.

Last time this came up was on a more private discussion.  Arguments
both ways were given, and (IIRC) we decided to split the install
hierarchy (for release(7) and for prebuilt packages) but, IIRC, not to
change the MACHINE_ARCH.  If you need to know the endian-ness, it's in
       `sysctl hw.byteorder`