ABIv1 to ABIv2 toolchain changes

The principal task of Symbian OS 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 OS. Symbian OS 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:

The elf2e32 tool replaces the ABIv1 toolchain tools def2dll.bat, prepdef.pl, 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.