ABIv1 -to ABIv2 toolchain changes

The principal task of Symbian platform build tools such as abld/makmake 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.

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 elf2e32.exe). -This redesign is intended to simplify the work needed to introduce support -for a new ABIv2 compatible compiler into the toolchain.

The following diagram shows the steps (somewhat simplified) performed by -the toolchain for the creation of a DLL for ABIv1 and v2 respectively:

- - ABIv1 and v2 toolchains compared - - -

The elf2e32 tool replaces the ABIv1 toolchain tools def2dll.bat, elf2inf.pl, makedef.pl and elftran.exe.

.dso files

In the ABIv2 toolchain, .lib files -are replaced by .dso files. These files are used in similar -situations to .lib files. However, the format of these -two files is completely different. A .lib file is an -archive file created from stubs generated for each of the exported symbols. -A .dso 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 .dso file -also has the information required for the linker to link to the correct ordinals -to the DLL. .lib files cannot be used by the ABIv2 toolchain, -and .dso files cannot be used by the ABIv1 toolchain.

Linked objects

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.

E32Image format

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.

+ + + + + +ABIv1 +to ABIv2 toolchain changes +

The principal task of Symbian platform build tools such as abld/makmake 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.

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 elf2e32.exe). +This redesign is intended to simplify the work needed to introduce support +for a new ABIv2 compatible compiler into the toolchain.

The following diagram shows the steps (somewhat simplified) performed by +the toolchain for the creation of a DLL for ABIv1 and v2 respectively:

+ + ABIv1 and v2 toolchains compared + + +

The elf2e32 tool replaces the ABIv1 toolchain tools def2dll.bat, elf2inf.pl, makedef.pl and elftran.exe.

.dso files

In the ABIv2 toolchain, .lib files +are replaced by .dso files. These files are used in similar +situations to .lib files. However, the format of these +two files is completely different. A .lib file is an +archive file created from stubs generated for each of the exported symbols. +A .dso 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 .dso file +also has the information required for the linker to link to the correct ordinals +to the DLL. .lib files cannot be used by the ABIv2 toolchain, +and .dso files cannot be used by the ABIv1 toolchain.

Linked objects

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.

E32Image format

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.

\ No newline at end of file