[gccsdk] Converting ELF into AOF or ALF?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riscos.info/pipermail/gcc/attachments/20150815/90c76b4a/attachment.html>

More information about the gcc mailing list