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