Support for Amiga 0x3F3 binary format

[Nick Clifton]

Hi Simon,

>I'm thinking about implementing support for the Amiga's executable
>format into binutils,
>
This sounds like fun :-)

> - Linking m68k and powerpc objects together, resulting in an
>   application that requires an m68k and uses a powerpc CPU if it is
>   present.
>
>Here is where it gets hairy. A system that does not have a powerpc board
>installed does not know the ppc specific section types and fails to load
>the binary, thus these sections need to be placed in an overlay and
>loaded by special startup code when the powerpc is present. The app
>would then (independently) determine whether the ppc is there and use
>it.
>
> - Disassembling an application
>
>I have no clue how to go on about this. The best option would probably
>be skipping over code sections for the "other" CPU type and requiring
>people who want to disassemble stuff to invoke both m68k-amigaos-objdump
>and powerpc-amigaos-objdump.
>  
>
The problem here is knowing which kind of code is held in which 
sections.  If you are going to have "magic" section names, then you are 
going to have to add code to GDB to handle this.  Similarly you will 
need to add code to objdump (and readelf) as well.  I suspect that 
getting this to work will be quite difficult and hard to do without 
introducing much ugliness into the binutils code base...

A much cleaner approach - if it is possible - is to keep the two kinds 
of binary separate.  ie link together the m68k object files into one 
executable and the powerpc object files into a second executable.  Then 
you can either have a clever piece of loader code which looks at the 
name of the executable that contains it (eg "myprog.m68k") determines if 
a powerpc board is available and if so loads the equivalent program 
("myprog.ppc") onto it.

Basically the current binutils sources have no real support for 
multiple-architecture files.  (With exceptions for special cases like 
instruction sets which come in two size, eg ARM and THUMB).  Even in 
these cases special code has had to be added to binutils and GDB to 
handle the different instruction sets.  So although there is no 
theoretical reason why it cannot be done, you will probably find it, 
umm, difficult.


> - How should the targets be named? Is "m68k-unknown-amigaos" (derived
>   from m68k-amigaos) and "powerpc-unknown-amigaos" (likewise) okay?
>  
>
Yup, those sound fine.  Is the amigos file format a proprietary format 
?  If so then we may not be able to include it in the binutils sources....

> - It is pretty clear that most of the code will be common to the m68k
>   and powerpc targets, and that this code should support every feature
>   there is. However, what object format should I report for hybrid
>   binaries?
>  
>
The containing format. ie if the file is an m68k executable with a 
special powerpc section inside it then report the binary as being 
m68k-unknown-amigos.

> - When building support for the powerpc side of things, the startup
>   codes would have to be built for m68k. Should I:
>    + Generate the startup code in maintainer mode only, requiring
>      people who modify the asm to have an assembler for the m68k target
>      installed?
>    + Build a small assembler in a subdir and assemble the code
>      everytime it is needed?
>    + Do something else?
>  
>
Do something else.   The startup code is not really something that 
should be included in the binutils.  Instead it should be part of the 
newlib project or the BSP project.  (Both of which are on Sourceware).

Cheers
  Nick