<?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_d0e730488_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>