linux-mips-fnet
[Top] [All Lists]

Re: Problems with binary file formats...

To: linux-mips@fnet.fr
Subject: Re: Problems with binary file formats...
From: Systemkennung Linux <linux@mailhost.uni-koblenz.de>
Date: Tue, 23 Jan 1996 14:44:45 +0100 (MET)
In-reply-to: <199601230153.SAA01413@rover.village.org> from "Warner Losh" at Jan 22, 96 06:53:40 pm
Hi,

> : Yes.  Fortunately the DEC system boots a bootloader out of the first n
> : (16?) blocks of the disk, so only the boot loader need know about
> : where to find the kernel.  In my mind, this boot loader is just a
> : modified version of lilo...
> 
> Yup.  Heck, you could replace the read/write/open commands that are
> there now with ones of your own and it should just work.  I have a dim
> memory of Andy saying that he did this to test it under an OS that is
> POSIX compliant before rebooting the machine...

Yes, this are the original idea when I wrote that stuff.  Aside of that
these wrapper routines also proofed to be a wonderful place to hide
ARC BIOS workarounds.  And then there is this stupid (C) problem with
the ARC documentation that we also solved that way.  I hope we can finally
solve that in direction of a fully GPL'ed Milo source as soon as SNI gives
us ARC docs.

> : Yep - I'm sure that with the right amount of fussing with GNU config
> : files, we could build gcc/binutils that knew about all formats: a.out,
> : ELF, ECOFF, ECOFF-DEC... at least, I sincerely hope we can so that we
> : have a single consistent development tool chain.
> 
> Likely...  I'm still trying to figure out how to get my elf tools to
> generate ECOFF, but I haven't looked hard.

Look at the Milo source tree.  Milo uses the normal a.oout or ELF compiler
and links the output to ECOFF.  Just a single option.  As alternative
setting the environment variable GNUTARGET to the desired target would
also work but I think this is inconvenient.

> Hmmm, I recall that the 4G DAT drives are about US$500 here in the
> states generally.  Not cheap, but not horribly expensive.
> 
> One of the other hacks I want to do at some point is to hack FreeBSD's
> dump program to automatically compress the data before writing it to
> tape and restore when reading it back from tape...  Don't know if my
> machine is fast enough to keep up with it.  However, what I have now
> works, so I'm not massively motivated just yet.

Just say "Backups are for wimps" ;-)

  Ralf

<Prev in Thread] Current Thread [Next in Thread>