Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 85
Текст из файла (страница 85)
It calls the finder’s Search() method – commencing thesearch scheme as outlined in the first part of Section 10.3.2.1. Assumingthe search is successful, the loader now populates the main E32Imageobject with information on the executable file it has found, by calling theE32Image::Construct() method.Figure 10.4 shows this second phase. Note that we assume here thatthe paths searched are not held in the loader cache, and so searchinginvolves making requests on the file server to read the directory entries.The loader also needs to open candidate files to read information fromtheir ROM image header, but this is not shown in the figure. Becausethe entire ROM image is always mapped into user-readable memory,404THE LOADERloader thread file server threadE32Image::LoadProcessRImageFinder::SearchRDir::OpenCSessionFs::ServiceLCSessionFs::ServiceLTDrive::DirOpenCDirCB::ReadLE32Image::ConstructRDir::ReaduserkernelFigure 10.4 Locating the process executablethe loader can access the ROM image headers via a pointer rather thanhaving to use the file server to read them.10.3.6.3 Creating the code segment and processThe next stage is to check whether a DCodeSeg object corresponding to this executable already exists (that is, the executable is alreadycurrently loaded).
To do this, the loader uses the executive functionE32Loader::CodeSegNext() to request that the kernel search itsentire list of code segments looking for one with a ROM image headerpointer that matches with the one about to be loaded. If a match is found,the loader sets E32Image::iHandle for this segment, and then opensit for a second process.The loader now calls the executive function E32Loader::ProcessCreate() to request that the kernel create the process structure, mainthread and global data chunk. This results in a DProcess object beingcreated for the process. If no DCodeSeg object was found to exist earlier,this in turn leads to the creation of a DCodeSeg object for this executable.As I have said, since this is a code segment for a ROM executable, thereis no associated memory area and no need to load any code into thesegment from the executable file or perform any code relocations.I describe this phase of process loading in more detail at the start ofSection 10.4.3.10.3.6.4 Processing importsNext the loader must load any DLLs that the executable depends on andwhich contain static data.
To do this, it gets the address of the DLL reference table from the ROM image header and starts to process the entries.Each entry holds a pointer to the image header of the DLL concernedand, for each, the loader generates a further E32Image object, whichit then populates with information read from the corresponding imageTHE LOADER SERVER405header. The loader must also obtain a DCodeSeg object for each entry.This is a procedure that starts in a similar manner to the one performedearlier – searching through the list of existing code segments. However,if it needs a new DCodeSeg object, the loader calls the executive function E32Loader::CodeSegCreate() to create the object, followed byE32Loader::CodeSegAddDependency() to register the dependencyin code segments between importer and exporter.
If any dependenciesthemselves link to other DLLs, then they too must be loaded and theloader may call the function that handles loading dependant DLLs,E32Image::LoadDlls(), recursively to process these.Now the loader calls the executive function E32Loader::CodeSegLoaded() for each new DCodeSeg object created (except that of theDCodeSeg belonging to the process executable itself) to mark these asbeing loaded.I describe the kernel’s involvement in this DLL loading in more detailin Section 10.4.4.Figure 10.5 shows the program flow as the loader creates the processand handles its import dependencies.loader threadE32Image::LoadProcessE32Image::ConstructE32Loader::ProcessCreateE32Loader::CodeSegNextE32Image::ProcessImportsE32Image::LoadDllsE32Image::FinaliseDllsE32Loader::CodeSegCreateE32Loader::CodeSegLoadeduserkernelExecHandler::CodeSegNextExecHandler::CodeSegCreateExecHandler::ProcessCreateExecHandler::CodeSegLoadedFigure 10.5 Creating the process and handling its import dependencies10.3.6.5 Completing the requestIn the final stage of loading a process, the loader calls the executivefunction E32Loader::ProcessLoaded() to update the state of thenew process’s thread.
(If the DCodeSeg object of the process executableis new, and not shared from a preexisting process, this internally marksthe DCodeSeg object as being loaded.) This function also generates ahandle on the new process, relative to the original client thread. Theloader then writes the handle back to the client.Next, the loader deletes all the image objects it has created for theexecutables involved and closes its own handle on the new process.406THE LOADERFinally it completes the original load process message, and controlreturns to the client thread.
This closes the RLoader session object andthe method RProcess::Create() finally returns.I describe the kernel involvement in this final phase in more detail atthe end of Section 10.4.3.Figure 10.6 shows this last phase.client thread loader threadRProcess::CreateCSessionLoader::ServiceLRLoader::LoadProcessE32Image::LoadProcessE32Loader::ProcessLoadeduserkernelExecHandler::ProcessLoadedFigure 10.6Completing the requestAssuming the process load was successful, the client then needs toresume the new process for it to run.
However, the loader has done itsjob by this stage and is not involved in this.The kernel then calls the process entry point, which creates the mainthread heap. Next it copies the initialized data section to its run addressand clears the un-initialized data area. Then it calls constructors for theEXE itself and for implicitly linked DLLs. Finally it calls the process’spublic entry point, the E32Main() function.There are a number of differences in the way an executable is loadedfrom ROM on EKA2, compared to EKA1.
Firstly, in EKA1 a third server,the kernel server, is involved; this runs in supervisor mode. The loadermakes a request on the kernel server, asking it to create the new process.On EKA2, process creation is done in supervisor mode too – but in thecontext of the loader server. Secondly, in EKA1, the loader copies theinitialized data section from ROM to the global data run address as partof the process load operation. However, in EKA2, this data copying isperformed kernel-side, and is deferred until the initialization phase ofprocess execution.10.3.7 Loading a process from non-XIP mediaThis is similar to the loading of a process from XIP media, but morecomplex.
Since the media is non-XIP, the code must be loaded into RAMTHE LOADER SERVER407for execution. Also, since the import sections and relocations have notbeen fixed up in advance, these sections need to be processed too.10.3.7.1 Locating the process executableThe first difference occurs at the point where the loader searches forthe process executable.
If it needs to load header information from acandidate file (on a loader cache ‘‘miss’’), then this requires a full fileserver read request, rather than relying on the ROM image being memorymapped.10.3.7.2 Creating the code segment and processThe next difference occurs when the loader calls E32Loader::ProcessCreate() and the kernel creates a DCodeSeg objectfor the process executable. Since the process is not XIP, the kernel allocates a RAM code segment, associates this with the DCodeSeg objectand returns the code load address within this segment.The loader now needs to load the entire code section from the imagefile into this code segment at the code load address. If it is a compressedDProcessA.EXEE.DLLB.DLLC.DLLD.DLLFigure 10.7Sample non-XIP code graphF.DLL408THE LOADERDProcessA.EXEB.DLLC.DLLFigure 10.8D.DLLCode graph with some XIP modulesDProcessA.EXED.DLLFigure 10.9 Code graph with all XIP modulesTHE LOADER SERVER409executable, the loader also needs to decompress the code section as itloads it.
However, unlike on EKA1, the code segment does not haveuser-write permissions and so the loader can’t directly copy data into it.Instead it uses an executive function to perform this in supervisor mode.If decompression is required, the loader reads portions of the code fromthe file into a buffer, decompresses it, and then makes use of the userlibrary function UserSvr::ExecuteInSupervisorMode() to moveit from buffer to code segment in supervisor mode.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
