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