--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,59 @@
+<?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>
\ No newline at end of file