This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Support for Amiga 0x3F3 binary format


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: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]