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] |
This sounds like fun :-)I'm thinking about implementing support for the Amiga's executable format into binutils,
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...- 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.
- How should the targets be named? Is "m68k-unknown-amigaos" (derivedYup, 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....
from m68k-amigaos) and "powerpc-unknown-amigaos" (likewise) okay?
- It is pretty clear that most of the code will be common to the m68kThe 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.
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 startupDo 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).
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?
Cheers Nick
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |