Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 82
Текст из файла (страница 82)
It doesn’t exist as aseparate entity in an E32 image file. It may exist in the PE or ELFformat file from which the E32 image file is derived, but the tools thenamalgamate it into the .text section.4) The import address table (IAT)This table contains an entry for each function imported by the executable,as follows:OffsetDescription00Ordinal of import 104Ordinal of import 2...4(n − 1)4nOrdinal of import nNULLFor each function that the executable imports, the file will contain animport stub function within the code section. When executed, each stubwill load the program counter with the value from the correspondingentry of the IAT.Therefore, when the executable is loaded, the loader has to fix up eachentry in the IAT, replacing the ordinal number with the run address ofthe imported function. It has to calculate the address using the contentsof the .idata section of this executable together with the .edata section ofthe DLL that exports the function requested.Note that executables originating from ELF format files don’t containan IAT.
For these, the tools fix up the import stubs directly – they obtainthe location of the stub from the import data section.The order of the entries in the IAT corresponds precisely with the orderthat imports are listed in the .idata section.5) The export directory – .edataThe export directory is a table supplying the address of each functionexported from this executable. Each entry holds the start address of thefunction as an offset relative to the start of the code section:E32 IMAGE FILE FORMAT00Address of 1st function exported from this executable.04Address of 2nd function exported from this executable.389...4n − 4Address of last function exported from this executable.The order of exports in the table corresponds to the order in the DEFfile for this executable.
The table is not null terminated. Instead, thenumber of entries in the table is available from the file’s image header.6) Initialized data section – .dataThis section contains the initialized data values that are copied to RAMwhen this executable runs.7) Import data section – .idataThis section contains data on each function that this executable imports.The loader uses this information to identify each referenced DLL that italso needs to load. Additionally, the loader uses this information to fix upeach entry in the import address table (IAT).The format of this section is as follows:FieldSizeDescriptionA word holding the size of this section inbytes (rounded to 4-byte boundary).Import block for DLL1Import block for DLL2......Import block for DLLnName of DDL1NULL terminated ASCII string.Name of DLL2NULL terminated ASCII string.......Name of DLLnNULL terminated ASCII string.As well as the file name itself, the DLL name string also includesthe required third UID.
If the file was built with the EKA2 tool set, the390THE LOADERname string will also contain the required version number of the DLL(see Section 10.3.1). The loader will have to match all of these when itsearches for the imported DLL. The format of the name is as follows, withUID and version in hexadecimal:<filename>{versionNum}[uid3]<extension>for example, efsrv{00010000}[100039e4].dllThe format of each import block depends on whether the executableoriginated from a PE or an ELF format file. For PE derived files, it has thefollowing format:OffsetDescription00HOffset of DLL name from start of .idata section.04HNumber of imports for this DLL.For PE-derived executables built with the EKA1 tool set, this importblock also contains a list of ordinals for the DLL concerned. However, thisinformation is a duplicate of that contained in the import address table,so import blocks no longer contain this information when built with theEKA2 tool set.Import blocks for ELF derived files have the following format:OffsetDescription00HOffset of DLL name from start of .idata section.04HNumber of imports for this DLL.08HThe location of import stub for the 1st function imported from this DLL.(This is an offset within the code segment of the importing executableto the location that will be fixed up with the address of the importedfunction.)0CHThe location of import stub for the 2nd function imported from this DLL.......The location of import stub for the last function imported from thisDLL.8) Code relocation sectionThis section contains the relocations to be applied to the code section.The format of the table is shown next:E32 IMAGE FILE FORMATOffset391Description00HThe size of the relocation section in bytes (rounded to 4-byteboundary).04HNumber of relocations.08HRelocation information.0CHRelocation information.......Nn00000HThe format used for the relocation information block differs slightlyto the standard Microsoft PE format.
It consists of a number of subblocks, each referring to a 4 KB page within the section concerned. Eachsub-block is always a multiple of 4 bytes in size and has the followingformat:OffsetDescription00HThe offset of the start of the 4 KB page relative to the section beingrelocated.04HThe size of this sub-block in bytes.08H2 byte sub-block entry.The top 4 bits specify the type of relocation:0 – Not a valid relocation.1 – Relocate relative to code section.2 – Relocate relative to data section.3 – Try to work it out at load time (legacy algorithm).The bottom 12 bits specify the offset within the 4 K page of the itemto be relocated.0AH2 byte sub-block entry.......9) Data relocation sectionThis section contains the relocations to be applied to the data section.The format of the table is the same as that for code relocations.392THE LOADERThe nine sections that I have just listed apply to the structure of theexecutable files as they are stored on disk.
However, once an executablehas been loaded by the Symbian OS loader, it consists of two separatelyrelocatable regions (or sections). The first is the code section, whichincludes the code, import stubs, constant data, IAT (if present) and theexport directory (.edata). The second is the data section, which includesthe un-initialized data (.bss) and initialized data (.data).10.2ROM image file formatThe format that I described previously applies to executables that arelocated on drives which are not execute-in-place (XIP) – for example,executables contained within a NAND Flash ROFS image, on the userdata drive (C:) or a removable media disk (D:).
On such media, executablecode first has to be loaded into RAM (at an address which is not fixedbeforehand) before it can be run. However, by definition, for executablesstored in XIP memory (such as ROM) there is no need to load the codeinto RAM for execution.The ROMBUILD tool assembles the executables and data files destinedfor the ROM into a ROM image. The base address of the ROM and theaddress of the data sections are supplied to this tool as part of theROM specification (that is, the obey file) when it is run. In fact, forcertain executables, ROMBUILD itself calculates the address of the datasections.
These include fixed processes, variant DLLs, kernel extensions,device drivers and user-side DLLs with writeable static data. With thisinformation, ROMBUILD is able to pre-process the executables, performthe relocations and fix up the import stubs. The result is that on XIPmemory, executables have a format that is based on E32 image formatbut differs in certain ways, which I will now list:• They have a different file header, TRomImageHeader, which isdescribed in Appendix 3, The TRomImageHeader• They have no IAT; it is removed and each reference to an IAT entry isconverted into a reference to the associated export directory entry inthe corresponding DLL• They have no import data (.idata) section; it is discarded• They have no relocation information; it is discarded• They include a DLL reference table after the .data section.
This is a listof any libraries referenced, directly or indirectly, by the executablethat have static data. In other words, libraries with initialized data(.data) or un-initialized data (.bss) sections. The file header contains apointer to the start of this table. For each such DLL referenced in thetable, the table holds a fixed-up pointer to the image header of theDLL concerned.
See the following table:THE LOADER SERVEROffset393Description00HFlags.02HNumber of entries in table.04HImage header of 1st DLL referenced.08HImage header of 2nd DLL referenced.......nnImage header of last DLL referenced.These differences mean that the size of these files on ROM is smallerthan the corresponding E32 image file size.Another consequence of the pre-processing of the IAT and the removalof the import section for ROM files is that it is not possible to over-ridea statically linked DLL located in ROM by placing a different version ofthis referenced DLL on a drive checked earlier in the drive search order,such as C:.10.3 The loader serverThe RLoader class provides the client interface to the loader and iscontained in the user library, EUSER.DLL.
However, user programs haveno need to use this class directly – and indeed they must not use it sinceit is classified as an internal interface. Instead the RLoader class is usedprivately by various file server and user library methods. These include:• RProcess::Create() – starting a new process• RLibrary::Load() – loading a DLL• User::LoadLogicalDevice() – loading an LDD• RFs::AddFileSystem() – adding a file system.RLoader is derived from RSessionBase and is a handle on a sessionwith the loader server.
Each request is converted into a message that issent to the loader server.Unlike the file server, the loader server supports only a small numberof services. These include:• Starting a process – loading the executable concerned394THE LOADER• Loading a DLL• Getting information about a particular DLL. (This includes informationon the DLL’s UID set, security capabilities and module version)• Loading a device driver• Loading a locale• Loading a file system or file server extension.10.3.1 Version numberingIn EKA1, it is only possible for one version of a particular executable toexist in a Symbian OS phone at any time. This is not the case for EKA2,whose loader and build tools support version numbering – a scheme thatassociates a version number with each executable.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
