<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72" xml:lang="en"><title>ABIv1
to ABIv2 toolchain changes</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The principal task of Symbian platform build tools such as <filepath>abld/makmake</filepath> is
to read the specified project (.mmp) files and then call the appropriate compiler
and linker with the necessary inputs and option settings. The binaries output
from commercial compiler and linkers, such as ARM's RVCT and GNU GCC, cannot
however be directly used by Symbian platform. Symbian platform requires binaries
to be in Symbian-specific format, known as the E32Image format. </p>
<p>In order to create binaries in this format, the toolchain must perform
additional steps on the compiler/linker output. How these steps are performed
is considerably different between builds for the ABIv1 and ABIv2 targets.
Essentially, a number of small tools used for ABIv1 targets, are replaced
for ABIv2 targets by a single tool called the post-linker (file name <filepath>elf2e32.exe</filepath>).
This redesign is intended to simplify the work needed to introduce support
for a new ABIv2 compatible compiler into the toolchain. </p>
<p>The following diagram shows the steps (somewhat simplified) performed by
the toolchain for the creation of a DLL for ABIv1 and v2 respectively: </p>
<fig id="GUID-F68AB795-A612-5202-A459-30B62663737F">
<title>           ABIv1 and v2 toolchains compared          </title>
<image href="GUID-09263C33-EE63-530C-A6B9-70806F0BC16D_d0e417162_href.png" placement="inline"/>
</fig>
<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>
<section><title>.dso files </title><p>In the ABIv2 toolchain, <filepath> .lib</filepath> files
are replaced by <filepath>.dso</filepath> files. These files are used in similar
situations to <filepath>.lib</filepath> files. However, the format of these
two files is completely different. A <filepath>.lib</filepath> file is an
archive file created from stubs generated for each of the exported symbols.
A <filepath>.dso</filepath> file is an ELF object similar to other objects
created with the compiler. It has all the associated sections required for
an ELF object, such as the symbol table, string table, etc. The <filepath>.dso</filepath> file
also has the information required for the linker to link to the correct ordinals
to the DLL. <filepath>.lib</filepath> files cannot be used by the ABIv2 toolchain,
and <filepath>.dso</filepath> files cannot be used by the ABIv1 toolchain.</p></section>
<section><title>Linked objects </title><p>The compiler toolchain that supports
ABIv2 produces linked objects that are different to those produced by the
ABIv1 toolchain. The linked objects produced are both ELF format, but they
have extra information that can be used by a postlinker to create platform
specific binaries. As the ELF produced by ABIv2 has more information, it is
not necessary to perform the sort of manipulations performed by the many small
tools in the ABIv1 toolchain. As the linked objects differ significantly in
their content, it is not possible to mix ABIv1 and ABIv2 toolchain objects
in the same build tree. </p></section>
<section><title>E32Image format </title><p>The final E32image produced by
the ABIv2 toolchain is in the same format as that of the ABIv1 toolchain.
However, a byte by byte comparison of the same E32image file in ABIv1 and
ABIv2 is not possible. The layout of the code produced by the linker is different,
although the code is still binary compatible. </p></section>
</conbody></concept>