Re: Support for Amiga 0x3F3 binary format

[Simon Richter <Simon dot Richter at hogyros dot de>]

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