Re: [gccsdk] Converting ELF into AOF or ALF?

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 svn://svn.riscos.info/gccsdk/trunk/tools/elftoolchain/ with 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 done).
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 support.

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  missed?  

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,
John.