Some MIPS status goodies.

juli mallett jmallett at
Thu Jun 10 23:24:58 GMT 2004

* Ralf Baechle <ralf at> [ Date: 2004-06-10 ]
	[ w.r.t. Re: Some MIPS status goodies. ]
> On Thu, Jun 10, 2004 at 12:17:46PM -1000, juli mallett wrote:
> > > 64-bit ELF requires very recent GNU tools and even in those it cannot
> > > be considered of prime quality.
> > 
> > Right now I'm struggling with the more loathsome problem of
> > elf<mumble>-{,trad}{big,little}mips ...  Just where do you and don't
> > you need the "trad" -- this seems to be a painful thing, certainly
> > it has been for me, and I'm hoping that BU (namely BFD) will grow
> > some more friendly compilation conditionals in the future, but I'm
> > not going out of my way for that...  Certainly I'm happy with my
> > working elf32-tradbigmips toolchain.
> >From my experience forget about the non-trad variant.  trad*mips is ABI
> ELF (or rather ABI ELF with GNU breakage); the non-trad variants are
> IRIX ELF with it's undocumented differences compared to ABI ELF.  The
> nasty stuff about IRIX ELF is that some of it's difference also affect
> generic ELF.
> We used to use non-trad ELF for Linux until we hit a problem with modutils
> which was explained by the difference between non-trad ELF and trad ELF,
> so we switched.  I think this is the only time the difference between the
> two actually did matter to us.

non-trad elf has a lot of problems.  But just having trad stuff, while fine
for config.bfd, seems to cause havoc with the BU build environment FreeBSD
uses and I can't figure out what's up.  I get some of BU's lovely obscure
messages there which make me think something is very borked.

The non-trad stuff, in 64 bit mode, also wants stuff like rld_map which I am
fundamentally opposed to adding.

> > > 64-bit code is so much larger that it often delivers just half the
> > > performance of 32-bit code.
> > 
> > FreeBSD/MIPS is definably 64-bit code, just 32-bit ELF for now.
> Ah, that sounds like the hack which I'm using also.  Initially born due
> to the complete unusability of NABI ELF this code model turned into the
> code model of choice because it's so much more efficient and smaller -
> the difference is in the range of hundreds of kB for an IP27 kernel.
> The problem is this may become impossible with later GNU tools but let's
> see what can be done about that.

Works well enough as long as you have CKSEG around :(  (or a sufficiently
complex bootloader and simple enough system that you can cheat and run it
out of user address space.)
juli mallett.  jmallett at  adrift in the pacific.

More information about the freebsd-mips mailing list