<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/15/2015 01:54 PM, Steve Fryatt
      wrote:<br>
    </div>
    <blockquote
      cite="mid:mpro.nt4h38011deg201xh.lists@stevefryatt.org.uk"
      type="cite">
      <pre wrap="">[...]
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, </pre>
    </blockquote>
    <br>
    There are several aspects to consider:<br>
    <ol>
      <li>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.</li>
      <li>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 (<a class="moz-txt-link-freetext" href="http://elftoolchain.sf.net">http://elftoolchain.sf.net</a>, 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.</li>
      <li>The semantics : this is where things get interesting.  ELF is
        much richer in semantics than AOF so this will require some
        attention.</li>
      <ul>
        <li>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.<br>
        </li>
        <li>Symbol & string table : should not be that hard to
          convert.<br>
        </li>
        <li>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.</li>
        <li>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).</li>
      </ul>
      <li>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.<br>
      </li>
    </ol>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
      cite="mid:mpro.nt4h38011deg201xh.lists@stevefryatt.org.uk"
      type="cite">
      <pre wrap="">[...] 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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <blockquote
      cite="mid:mpro.nt4h38011deg201xh.lists@stevefryatt.org.uk"
      type="cite">
      <pre wrap="">[...] 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!</pre>
    </blockquote>
    <br>
    As conclusion, I believe this is a very reasonable idea/project, not
    straightforward but feasible.<br>
    <br>
    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.<br>
    <br>
    <blockquote
      cite="mid:mpro.nt4h38011deg201xh.lists@stevefryatt.org.uk"
      type="cite">
      <pre wrap="">Or, even better, is there already a solution out there that Google has
missed?
</pre>
    </blockquote>
    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.<br>
    <br>
    Hope this helps,<br>
    John.<br>
    <br>
  </body>
</html>