Some MIPS status goodies.

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


* Ralf Baechle <ralf at linux-mips.org> [ 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 freebsd.org.  adrift in the pacific.


More information about the freebsd-mips mailing list