Symbian3/SDK/Source/GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72.dita
changeset 7 51a74ef9ed63
child 8 ae94777fff8f
equal deleted inserted replaced
6:43e37759235e 7:51a74ef9ed63
       
     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_d0e469621_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>