[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] obsolete aout binutils?



Hi,

Frank Naumann wrote:
Hello!

Later, mint could start supporting natively the elf binary format.
But at this moment I think it's easier to modifie the "elf2flt" tool for our purposes.

Are you sure this is possible? The biggest problem of the MiNT port of the binutils was to remember all relocations and write the relocation information table that is needed by the Atari format (it's even not unix a.out). Normally (for ELF and a.out) you lose all relocation informations during linking as ELF and a.out always relocate to a fixed address. I don't know how ulinux handle this.

ELF and a.out are just container formats. On other platforms ELF and a.out executables usually have _no_ relocation information. On the other hand both formats do of course support relocation information, and in principle it should be possible to define an ELF or a.out executable format with relocation information included.

When I wrote the original patches to binutils for MiNT support my goal was to design a format that also ran without modifications on Atari machines without MiNT. That's why I used the somewhat funny format of the Atari resp. TOS relocation format. "My" format is therefore not a.out but a hybrid format, a mixture between classic a.out and the GEMDOS executable format defined by Atari.

Getting rid of the "obsolete a.out format" implies a modification to the operating system, losing compatibility to the non-MiNT world of the Atari community. These compatibility issues were a sacred cow, at the time I introduced my format. Things may have changed since then. But honestly, simply changing the container does not provide a real improvement on its own: You would - for example - still have to attach relocation information to binaries.

Sure, it would also be possible to make do without any relocation information at all, but I think that this would still require major modifications to gcc. The position independent code that gcc produces for m68k is probably (I would be glad to be proven wrong here) not position independent enough for the need of MiNT. And there would be no immediate benefit from it, as PIC is even slower than normal code.

Still I would encourage everyone to work in this direction, i. e. try to
experiment with ELF as binary format. You can start with object files, than libraries, and finally - after some kernel modifications - also for executables, although the latter is far less important than you might think. Even the current format would allow you to dynamically load shared libraries, even when they are only "shared" on disk, not in memory. But you have to start somewhere, and I would recommend the "easy" starting points here, the object and the library formats.

Ciao,
Guido
--
Imperia AG, Development
Leyboldstr. 10 - D-50354 Hürth - http://www.imperia.net/

Attachment: signature.asc
Description: OpenPGP digital signature