Support for Amiga 0x3F3 binary format

Support for Amiga 0x3F3 binary format

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 3023 bytes --]

Hi,

I'm thinking about implementing support for the Amiga's executable
format into binutils, however there are some issues because the format
allows binaries that contain code for two different architectures (m68k
and powerpc). While it is possible to execute powerpc ELF binaries
directly on the Amiga, the native format reqires a small chunk of m68k
startup code, and there is also the possibility of "mixed" binaries that
execute on both CPUs, or use the powerpc code only if the CPU is
present.

Typical use cases would be:

 - Creating an m68k linkable object
 - Creating a powerpc linkable object
 - Linking m68k objects together.

These three are pretty straightforward.

 - Linking powerpc objects together.
 - Converting binaries to and from ELF format.

These two require adding/removing startup code. I think tagging the
startup code by putting it into a section with a special name should
suffice.

 - Linking m68k and powerpc objects together, resulting in an
   application that requires both CPUs.

This is pretty straightforward again. The app is responsible for
initializing the powerpc side of things, so simply linking the app is
fine.

 - 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.

To make matters worse, there are also two competing "operating systems"
for the powerpc side, of which only one can run at a given time.

Okay, simple questions first:

 - How should the targets be named? Is "m68k-unknown-amigaos" (derived
   from m68k-amigaos) and "powerpc-unknown-amigaos" (likewise) okay?
 - 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?
 - 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?

   Simon

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 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

Re: Support for Amiga 0x3F3 binary format

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

Hi,

> >- 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.

That is not a problem, as there are separate section types for that
(CODE and PPCCODE). It is more a problem of having the appropriate
disassembler handy, since (as far as I've understood) there is usually
only one supported architecture, even though there may be multiple
platforms.

> 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.

It is possible, but quite ugly, as you will not be able to disassemble
existing binaries with this approach.

> Is the amigos file format a proprietary format?

Hrm, it is not really well-documented, as a lot of documentation simply
has been lost, but I've never heard of anyone having to sign something
in order to write code that reads or generates such files. I think I
should contact Amiga inc., who are the legal successors of CBM, about
this.

> >- 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.

Good.

> >- 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).

The idea behind the "startup code" approach is that there are certain
versions of the PowerPC OSes that can run PPC ELF binaries directly.
When converting such a binary to AmigaOS format, which requires an m68k
entry point, I'd like to be able to get a working executable at the end.

(This effort is basically inspired by the mess the Linux bootloader for
m68k and powerpc is in -- it has been compiled once, using gcc 2.5, and
now needs to be adapted to 2.6 kernels)

The "simple" startup code would basically open one of the powerpc
support libraries (which are resident, so if the open fails, no support
is present), push the registers onto the stack and invoke the startup
function on the ppc side, then, when that returns, close the library end
exit. I'd expect doing that in PIC code would need about 100-200 bytes.

   Simon

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Support for Amiga 0x3F3 binary format

[Ian Lance Taylor]

Simon Richter <Simon.Richter@hogyros.de> writes:

> That is not a problem, as there are separate section types for that
> (CODE and PPCCODE). It is more a problem of having the appropriate
> disassembler handy, since (as far as I've understood) there is usually
> only one supported architecture, even though there may be multiple
> platforms.

The assembler only supports one architecture at a time.  The rest of
the binutils are more flexible, and there is no such limitation.

Ian

Re: Support for Amiga 0x3F3 binary format

[Zack Weinberg]

Simon Richter <Simon.Richter@hogyros.de> writes:

> The "simple" startup code would basically open one of the powerpc
> support libraries (which are resident, so if the open fails, no support
> is present), push the registers onto the stack and invoke the startup
> function on the ppc side, then, when that returns, close the library end
> exit. I'd expect doing that in PIC code would need about 100-200 bytes.

It might be acceptable to code this, assemble it, and then embed the
machine code as a (commented!) hexadecimal array in the
target-specific code for this platform.  Similar things are done for
code sequences that have to be synthesized by the linker - take a look
at e.g. elfxx-ia64.c's plt_* arrays.

zw