Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 90
Текст из файла (страница 90)
This rule affects themoving and direct memory models. A code segment with writeablestatic data loaded into a fixed process will not be compatible withany other process, and such a code segment loaded into a movingprocess will be compatible with all moving processes but not withfixed processes.If the kernel finds that the selected code segment or the file being loadedis an XIP DLL with no .data/.bss and is not the explicit target of theload request, the function E32Image::DoLoadCodeSeg() returns atthis point. If the DLL is already loaded the function will have populatedthe E32Image object with information about the already-loaded DLL,including its code segment handle.
Execution then proceeds in the sameway as it would after the creation of a new code segment.If the kernel does not find the selected code segment, the E32Imageobject is populated with information read from the E32Image header ofthe selected file.The loader then calls E32Loader::CodeSegCreate(), passing inthe E32Image object; the latter derives from TCodeSegCreateInfo,which contains all the information the kernel needs to create a newcode segment. Figure 10.2 illustrates the relationship of these classes.The kernel-side handler ExecHandler::CodeSegCreate() verifies424THE LOADERthat the calling thread belongs to the F32 process, and then does someargument marshaling to get all the parameters over to the kernel-side, thistime including a handle to the loader’s client process, since that is theprocess into which the new code segment will be loaded.
Actual codesegment creation then proceeds as follows:1.The kernel creates a DMemModelCodeSeg object; this is the concrete class derived from DCodeSeg. There is only one such class inany given system and its definition depends on the memory modelin use. The generic kernel code calls the memory model functionM::NewCodeSeg() to instantiate such an object.
Once created,this object will contain all the information that the kernel needsabout the code segment2.The kernel copies the UIDs, attributes, full path name, root name,version number and dependency count (count of number of codesegments to which this one implicitly links) into the object. Itallocates an array to store the dependency linkages that make upthe code graph immediately below this code segment3.If the code segment is XIP, the kernel stores a pointer to thecorresponding TRomImageHeader in it4.If the code segment is a user-side EXE, then the process object withwhich the code segment was created will have been passed as aparameter. The kernel now creates the data/bss/stack chunk for thatprocess and commits sufficient memory to it to hold the process’s.data and .bss sections. On the multiple memory model, this chunk isalways at the same virtual address – 0x00400000 on both ARM andIA32. On the moving memory model, the virtual address dependson whether the process is fixed or moving and, if fixed, whetherit is XIP.
If XIP, the kernel uses iDataBssLinearBase fromthe TRomImageHeader. Moving processes have their .data/.bss at0x004000005.If the code segment is XIP, the kernel copies the EMarkData,EMarkDataPresent and EMarkDataInit flags from the TRomImageHeader, and sets the EMarkDataFlagsValid flag (sincethe ROM builder has already looked at all the dependencies).It reads the addresses of code and data, entry point, exceptiondescriptor and export directory from the TRomImageHeader andpasses them back to the loader. On the moving memory model,an XIP code segment with writeable static data loaded into a fixedprocess is marked as only available to that process by setting theiAttachProcess field of the code segment to point to the process6.If the code segment is not XIP, the kernel allocates memory tohold size and address information, and copies the size informationKERNEL-SIDE CODE MANAGEMENT425from the information passed by the loader.
If the code segmenthas writeable static data, the kernel sets the EMarkData, EMarkDataPresent, and EMarkDataFlagsValid flags, and also setsthe EMarkDataInit flag if the code segment is not an EXE codesegment. If the code segment does not have writeable static data,the kernel cannot determine the status of these flags until it hasresolved all dependencies7.For non-XIP code segments on the moving memory model, thekernel allocates an address and commits memory in either thekernel or user code chunks to hold the actual code.
For kernel-sidecode segments with writeable static data, the kernel allocates spaceon its heap to store the data. For user-side code segments withwriteable static data, the allocation of the data address dependswhether the code segment is destined for a fixed or moving process.For moving processes, the kernel allocates an address in the DLLdata address range (0x30000000 to 0x3FFFFFFF), but does notyet commit the memory.
For fixed processes, the kernel creates theprocess DLL data chunk if necessary and then commits memory toit to hold the static data8.Non-XIP code segments in the multiple memory model can be user,kernel or global (on the moving model, global is the same as user,since all code is visible to all processes). For kernel code segments,the kernel allocates an address for and commits memory to a specialkernel code chunk to hold the code itself, and allocates space forwriteable static data on the kernel heap. For global code segments,the kernel allocates an address for and commits memory to a specialglobal code chunk to hold the code itself – writeable static data isnot permitted.
For user code segments, the kernel allocates anaddress in the standard user code range and, if necessary, in theuser data range too. It allocates sufficient physical RAM pages tohold the code and attaches them to the code segment. At this point,memory is not yet allocated for any static data. The kernel thenmaps code pages into the current process (F32), at the allocatedaddress9.The kernel adds the code segment to the three global code segmentlists: unordered, ordered by name and ordered by run address10.The kernel sets the iAsyncDeleteNext field (usually zero fora DBase-derived object) to point to the code segment itself. Thisproperty is used subsequently in kernel executive calls that take acode segment handle to verify that the handle refers to a valid codesegment object42611.THE LOADERThe kernel passes the updated code segment information, includingthe allocated load-time and run-time addresses for the code anddata sections, back to the loader.After the new code segment is created, the loader reads in the codefrom the file system and relocates it to the address allocated by thekernel.
The loader also examines the import section of the loaded DLLand loads all implicitly linked DLLs. This is a recursive process, sinceeach new DLL will have its own implicit linkages, which will requirefurther DLLs to be loaded. When all required DLLs have been loaded, theloader resolves all import references between them. Then the loader callsE32Loader::CodeSegLoaded() on each one, finishing with the DLLthat was the explicit target of the original load request.
In this function,the kernel performs the following actions:1.It performs an IMB (Instruction Memory Barrier) operation on theaddress range of the loaded code. This ensures coherence betweenthe D and I caches on a Harvard cache architecture. (ARM processorswith separate instruction and data caches (everything after ARM7) donot maintain coherence between these two caches. So if a memorylocation is resident in the data cache and is dirty, that is, the valuehas been modified but not written back to main memory, the newvalue will not be fetched by an instruction fetch to that location.To ensure that the correct instruction is executed, it is necessary toclean the data cache – to write any modified data in the cache backto main memory – and to invalidate the instruction cache)2.On the multiple memory model, if the code segment is a standarduser-side code segment, the kernel unmaps it from the loader addressspace.
If the code segment is kernel code, the kernel changes thepermissions for the mapping from supervisor read/write to supervisor read-only. If the code segment is global code, it changes thepermissions from supervisor read/write to user read-only3.The kernel traverses the code graph recursively to ensure that theEMarkDataPresent and EMarkDataInit flags are set correctlyfor each code segment4.Finally the kernel sets the EMarkLoaded flag to indicate that thecode segment is fully loaded and ready for use.At this point, the DLL and all the DLLs on which it depends have beenloaded. This is the point at which execution continues after querying thekernel (in the case where the DLL was already loaded). The loader thencalls the kernel function E32Loader::LibraryCreate(), passing inthe code segment handle of the main subject of the load and a handleto the loader’s client thread.
In this call the kernel first looks at the clientSUMMARY427process to discover if a DLibrary representing the loaded code segmentalready exists in that process. If it does, the DLL is already loaded intothat process, so the only thing to do is to change the DLibrary stateto EAttached if it was originally EDetachPending (since the C++destructors have not been called there is no need to call the constructorsagain), and to create a new handle from the client thread or process tothe DLibrary, which is then passed back to the loader.If there is no DLibrary in the client process corresponding to theloaded code segment, the kernel creates a new DLibrary object andattaches it to the process. Then it maps the new code segment and all thecode segments in the sub-graph below it into the process address space(and increments their reference counts correspondingly).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
