[Freemint-list] binutils 2.28

[Vincent Rivière]

On 03/06/2017 at 03:52, Miro Kropáček wrote:
> Just wondering, in case the 
> https://github.com/freemint/m68k-atari-mint-binutils-gdb/issues/1 path is 
> taken, wouldn't be actually binutils the only component needed to produce 
> atari binaries? I.e. gcc would produce elf binaries/object files

Yes, exactly.
With maybe some minor adjustments in GCC. i.e the case of assembler labels 
for external C functions. Old a.out tradition is to prefix them with _ while 
standard ELF uses no prefix. Are we ready to fix *all* assembler sources of 
*all* software for this change? This is possible, but requires some 
significant work. The intermediate alternative is to tell ELF GCC to 
generate functions with leading underscore.

> and binutils would take care to convert it back to mint's a.out.

If you look at my experimental binutils "mintelf" branches, you will see it 
is already the case:
https://github.com/freemint/m68k-atari-mint-binutils-gdb/commits/binutils-2_19-mintelf

ld has the ability to mix object files of different types while linking. I 
feed it with ELF objects, and ask it to produce an a.out-mintprg executable. 
It just works. IIRC, GCC can even put old STABS debug info into .stabs 
sections of ELF objects. But ld is unable to merge the .stabs sections of 
ELF objects into real STABS (a.k.a. GNU debug info) in a.out executables. It 
is a lack of functionality in the GNU linker, and will probably never been 
done. The only drawback is that our gdb can't read any debug information. 
Probably not a big issue, as a.out is supposed (?) to be completely 
abandoned in gdb.

The above binutils experiments work, but I have only partially adapted GCC 
for it. It lacks support of C++ constructors of global variables, etc. But 
when I tried it was good enough to compile most C programs. And even able to 
successfully link old a.out libraries.

BTW, I have already exposed my vision of full-blown ELF support (different 
from the above):
TOS executables need a TOS header at the beginning.
ELF executables need an ELF header at the beginning.
Both are mutually exclusive, so an executable will never be both TOS and ELF.

Even if this will not work with (TOS and ELF), it could work with (TOS and 
almost-ELF). The key is that new almost-ELF executable format: basically a 
standard ELF with ELF header *not* at the beginning, but some bytes later. 
IMHO, it is just a matter of taking an ELF executable, reorganize sections 
properly, add a TOS header at the beginning, a TOS relocation table at the 
end, and you're done. Support for such binaries should be added to ld, maybe 
not so complicated. Then other binutils (such as objdump, objcopy, even gdb) 
should allow that format as input. I would bet it is very easy, just by 
asking the BFD library to look for ELF header not only at the beginning of 
the file, but also a few bytes after. And voila. After that, you have 
support for almost-ELF executables, both compatible with TOS/MiNT and GNU tools.

I'm sure that the above would be possible with a moderate amount of work.
But the question is: is it worth? would it change our lives?

-- 
Vincent Rivière