[gccsdk] Converting ELF into AOF or ALF?
John.Tytgat at aaug.net
Sat Aug 15 07:38:18 PDT 2015
On 08/15/2015 01:54 PM, Steve Fryatt wrote:
> Following a similar discussion on the ROOL forums recently, I was wondering
> about a tool to convert the ELF object files into AOF (and then ALF) --
> similar in concept to elf2aif, I suppose.
> Having had a quick look at the two formats, it seems that it might be
> possible to convert one into the other,
There are several aspects to consider:
1. ELF is a standard defined data container which gets used as
intermediate object code (alike AOF), static library file (alike
ALF), executables (alike AIF), shared library, core dumps, etc. So
we're talking about targeting a subset of ELF files in order to
convert them to AOF/ALF.
2. The file formats itself : I guess you'll need a good library to
access ELF data structures and AOF/ALF. For ELF, I liked ELF Tool
Chain (http://elftoolchain.sf.net, copy at
autotools support, also used in asasm for its ELF/DWARF output).
For AOF/ALF I don't think there is a general purpose one but luckily
those formats are very simple so you can probably very easily write
one yourself for this project.
3. The semantics : this is where things get interesting. ELF is much
richer in semantics than AOF so this will require some attention.
* How ELF sections (.text*, .(ro)data*, .bss, perhaps others) are
mapped to AOF areas. I assume the idea is that the AOF files
will be used by the Norcroft linker so the linking order what
Norcroft linker adheres to (which I believe is fixed) should be
more or less in line with the default linking script in binutils
link. I don't expect this being an issue but it is worthwhile
to investigate this for possible showstoppers.
* Symbol & string table : should not be that hard to convert.
* Relocations is going to be interesting as well. ELF ARM has
lots of relocations which need to be mapped to a few
combinations in AOF. Probably you're lucky here because in ELF
relocations are very instruction specific while in AOF it's the
linker which needs to recognize & support the instructions to be
able to apply the generic AOF relocation to them. So it might
just be a case to bulk mapping the ELF ones to AOF ones.
* Converting the DWARF debug information to AOF compatible one is
most probably impossible, perhaps maybe it it feasible to keep
the line number information (so single stepping in DDE could be
4. Testing : needs some thought, you might think you're generating a
valid AOF file but Norcroft's link might think otherwise. I guess
you'll need some testqueue exercising meaningful combinations and
see what Norcroft's link makes of it. I did similar things for
testing asasm AOF output and got some surprises but also insights.
Speaking of asasm, it might help to look at its sources to get up to
speed : internally its data structures are basically designed for AOF
and for ELF we translate AOF semantics to ELF. It might also be a
source for inspiration for the relocation part or its DWARF line number
Aside, elf2aif is a very simple hack : we reserve enough space at the
beginning of our first executable segment upfront and basically zap in
an AIF header in that space in the already linked ELF program file and
strip away the segments we're not interested in. Simple and very
effective but it won't help you for ELF->AOF/ALF.
> [...] but there's a nagging worry that
> even if I handle all of the symbol and relocation details correctly, the
> actual structures of the compiled code and data might not be compatible. Any
> files would be linked to the Shared C Library in the final instance, if that
> makes a difference.
I thinking you're hinting at possible ABI differences for both APCS-32
implementations. Indeed, a very valid consideration to make. gccsdk
targets APCS-32 for SCL (-mlibscl option) so in principle you should be
fine here except for one known issue : gccsdk differs from Norcroft C
compiler when float arguments are passed to functions. I can't remember
all the details (when to upgrade float -> double ?) but the SCL stubs
have a workaround for those SCL entries where float arguments are passed
for this exact reason.
I'm not aware of any other ABI differences (as far as I know the APCS
ABI never has been specified with great detail on all aspects of calling
convention, data layout composite types, etc.) but I wouldn't be
surprised if you start mixing Norcroft AOF files with GCCSDK AOF files
that you will find such issues. I don't think that has been done alot
before with the gccsdk 3.4.x (or earlier releases) which had AOF output.
> [...] So, before I waste too much time on this side project, is anyone already
> able to say that it /won't/ work for whatever reason? If so, there seems
> little point spending time reaching the same conclusion that other people
> have already reached before me!
As conclusion, I believe this is a very reasonable idea/project, not
straightforward but feasible.
I'm not wearing a GCCSDK hat anymore but actually if you would be doing
such a project, it would be a great addition to the existing gccsdk toolset.
> Or, even better, is there already a solution out there that Google has
I'm not aware of any off-the-shelve solutions. AOF/ALF has long time
been left along by the non-RISC OS/Acorn community, everyone is using
ELF (or COFF) these days.
Hope this helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gcc