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]

Re: Support for Amiga 0x3F3 binary format


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


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