1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72" xml:lang="en"><title>ABIv1

    13 to ABIv2 toolchain changes</title><prolog><metadata><keywords/></metadata></prolog><conbody>

    14 <p>The principal task of Symbian platform build tools such as <filepath>abld/makmake</filepath> is

    15 to read the specified project (.mmp) files and then call the appropriate compiler

    16 and linker with the necessary inputs and option settings. The binaries output

    17 from commercial compiler and linkers, such as ARM's RVCT and GNU GCC, cannot

    18 however be directly used by Symbian platform. Symbian platform requires binaries

    19 to be in Symbian-specific format, known as the E32Image format. </p>

    20 <p>In order to create binaries in this format, the toolchain must perform

    21 additional steps on the compiler/linker output. How these steps are performed

    22 is considerably different between builds for the ABIv1 and ABIv2 targets.

    23 Essentially, a number of small tools used for ABIv1 targets, are replaced

    24 for ABIv2 targets by a single tool called the post-linker (file name <filepath>elf2e32.exe</filepath>).

    25 This redesign is intended to simplify the work needed to introduce support

    26 for a new ABIv2 compatible compiler into the toolchain. </p>

    27 <p>The following diagram shows the steps (somewhat simplified) performed by

    28 the toolchain for the creation of a DLL for ABIv1 and v2 respectively: </p>

    29 <fig id="GUID-F68AB795-A612-5202-A459-30B62663737F">

    30 <title>           ABIv1 and v2 toolchains compared          </title>

    31 <image href="GUID-09263C33-EE63-530C-A6B9-70806F0BC16D_d0e469457_href.png" placement="inline"/>

    32 </fig>

    33 <p>The <filepath>elf2e32</filepath> tool replaces the ABIv1 toolchain tools <filepath>def2dll.bat</filepath>, <filepath>elf2inf.pl</filepath>, <filepath>makedef.pl</filepath> and <filepath>elftran.exe</filepath>. </p>

    34 <section><title>.dso files </title><p>In the ABIv2 toolchain, <filepath> .lib</filepath> files

    35 are replaced by <filepath>.dso</filepath> files. These files are used in similar

    36 situations to <filepath>.lib</filepath> files. However, the format of these

    37 two files is completely different. A <filepath>.lib</filepath> file is an

    38 archive file created from stubs generated for each of the exported symbols.

    39 A <filepath>.dso</filepath> file is an ELF object similar to other objects

    40 created with the compiler. It has all the associated sections required for

    41 an ELF object, such as the symbol table, string table, etc. The <filepath>.dso</filepath> file

    42 also has the information required for the linker to link to the correct ordinals

    43 to the DLL. <filepath>.lib</filepath> files cannot be used by the ABIv2 toolchain,

    44 and <filepath>.dso</filepath> files cannot be used by the ABIv1 toolchain.</p></section>

    45 <section><title>Linked objects </title><p>The compiler toolchain that supports

    46 ABIv2 produces linked objects that are different to those produced by the

    47 ABIv1 toolchain. The linked objects produced are both ELF format, but they

    48 have extra information that can be used by a postlinker to create platform

    49 specific binaries. As the ELF produced by ABIv2 has more information, it is

    50 not necessary to perform the sort of manipulations performed by the many small

    51 tools in the ABIv1 toolchain. As the linked objects differ significantly in

    52 their content, it is not possible to mix ABIv1 and ABIv2 toolchain objects

    53 in the same build tree. </p></section>

    54 <section><title>E32Image format </title><p>The final E32image produced by

    55 the ABIv2 toolchain is in the same format as that of the ABIv1 toolchain.

    56 However, a byte by byte comparison of the same E32image file in ABIv1 and

    57 ABIv2 is not possible. The layout of the code produced by the linker is different,

    58 although the code is still binary compatible. </p></section>

    59 </conbody></concept>