Re: [MiNT] ELF

[Vincent Rivière <vincent.riviere@freesbee.fr>]

The first question is:
Why ELF?

As far as I understand, the main advantages of ELF is the intermediate 
object file format. It allows gas and other tools to put extra information 
in custom sections of .o files. Then the linker can use this extra 
information to do special reorganization and optimization of .o files when 
building the final executable. That final executable can also contain extra 
sections, but basically (as a very rough approximation) that's just TEXT, 
DATA and BSS just like a.out and TOS executables.

It must be well understood that:

- Additional sections in ELF intermediate file format is useful for 
development tools, mainly between the assembler and the linker. This is why 
most new GCC features requires ELF.

- ELF executables are useful for the OS. They can store additional 
information in executables, such as DWARF debug information or any extra stuff.

What would be the benefit of ELF executables for the FreeMiNT kernel? I 
don't see any, except support for future extensions.

Another question is support for ELF dynamic libraries. As far as I 
understand, regarding to dynamic loading, this is unrelated to the 
executable file format. We could add new functions in the FreeMiNT kernel to 
dynamically load ELF libraries, just like SLB. This could even be added in a 
user library, without kernel support, just like LDG. Right now.

It must also be known that the GNU linker *is* able to mix different 
intermediate object file formats and link them together. Including libraries.

That being said:
6 years ago, I experimented something in binutils/GCC:
- ELF intermediate object file format
- classic a.out-mintprg executable format

The sources of this experimental work are here:
https://github.com/vinriviere/m68k-atari-mint-binutils-gdb/commits/binutils-2_19-mintelf
https://github.com/vinriviere/m68k-atari-mint-gcc/commits/gcc-4_4-mintelf

NB: Binaries were experimental and are not provided.

Such m68k-atari-mintelf-gcc produces ELF .o files, then classic TOS a.out 
executables. This worked surprising well. Debug information with -g (for 
gdb) is not supported, because the linker lacks support to convert STABS 
debug info from ELF to a.out (but it could).

This was long ago, I don't remember very well.
BUT IIRC, that toolchain was able to build new valid executables, while 
using the old a.out MiNTLib.
I surely built binutils and GCC for that target, but I didn't recompile the 
libraries due to lack of interest. But using the old a.out libraries as 
linker input worked very well.

If you look at the ELF patches, you will see that they are minimal. 
Actually, in GCC, I changed almost nothing (could be optimized for ELF, of 
course). In the binutils, I needed to fix a few things, but I have included 
them into the main binutils patch long ago :-) So the remaining ELF patch is 
almost minimal.

This m68k-atari-mintelf-gcc toolchain was just a hack, but it allows to make 
some experiments.

Le 20/03/2016 10:51, Markus Fröschle wrote:
> The a.out-mintprg target of the m68k-atari-mint toolchain isn’t really
> a.out. The above mentioned TOS relocation table functionality has just
> been added to the original a.out target because it was easiest to start
> from there. The same could be done to ELF targets, if somebody opted to
> do so.

Yes. The resulting binaries can't be 100% standard ELF executables, because 
they need to start with the "ELF" marker. But we could imagine adding a 
standard TOS executable header before ELF data, and a standard TOS 
relocation table at the end.

This "just" needs to create a new executable file format in the binutils, 
inspired from standard ELF and a.out-mintprg.

--
Vincent Rivière