📄 c-loader6.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Object-Module Loader </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="c-loader.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-loader.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-loader5.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-loader7.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="84938">3.6 Memory Management</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84940"> </a>The loader manages memory allocated from two entirely different memory pools. The loader is a component of a host process, the target server, and is able to allocate and free memory from the host heap using standard routines such as <b class="routine"><i class="routine">malloc</i></b><b>( )</b><b class="routine"><i class="routine"> </i></b>and <b class="routine"><i class="routine">free</i></b><b>( )</b>. However, the loader also manipulates data that it then transfers to the target system. The transfer requires the loader to allocate and free memory on the remote system as well. The loader does this through an internal library that manages a region of target system memory (the <i class="term">target server memory pool</i>). The memory manager on the host also implements a host cache for portions of the target memory; this minimizes the number of data transfers to and from the target.</p><dd><p class="Body"><a name="84942"> </a>To understand how the target server manages the target server memory pool, refer to the online reference material under <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Tornado API Reference>Target Server Internal Routines</font></b>. The routines listed are ANSI-compliant implementations; they have unique names to avoid conflicting with the host-system C library.</p><dd><p class="Body"><a name="84948"> </a>The interface to target server cache management is <b class="routine"><i class="routine">tgtMemCacheSet</i></b><b>( )</b>. This routine specifies the attributes of a block of host-mapped target memory. Blocks defined through this routine must not overlap. You must not change block boundaries once a block is created; however, you may call this routine again on a previously defined block to change its attributes.</p><dd><p class="Body"><a name="84949"> </a>The memory attributes of the target server memory pool are the following:</p></dl><dl class="margin"><dd><div class="Item"><a name="86427"> </a><b class="symbol_UC">MEM_NONE</b></div><dl class="margin"><dd><div class="Indent"><a name="86428"> </a>Return the region to the default attribute.</div><br></dl><dd><div class="Item"><a name="86430"> </a><b class="symbol_UC">MEM_NO_WRITE</b></div><dl class="margin"><dd><div class="Indent"><a name="84955"> </a>Flag as errors any writes to these memory regions by the host.</div><br></dl><dd><div class="Item"><a name="84957"> </a><b class="symbol_UC">MEM_HOST</b></div><dl class="margin"><dd><div class="Indent"><a name="84958"> </a>Allocate a block of memory to store all reads and writes locally. Do not modify target memory when writing to this region. This allows a module to be fully linked on the host before actually downloading it to the target.</div><br></dl><dd><div class="Item"><a name="84960"> </a><b class="symbol_UC">MEM_TEXT</b></div><dl class="margin"><dd><div class="Indent"><a name="84961"> </a>Allocate and store a block of memory on the host. Perform reads locally, but update both the local block and the corresponding address on the target when writing (like a write-through cache). This attribute is well suited for text segments once a module is fully linked.</div><br></dl></dl><dl class="margin"><dd><p class="Body"><a name="84962"> </a>To access target memory, all memory transfer requests must go through the routines <b class="routine"><i class="routine">tgtMemRead</i></b><b>( )</b>and<b class="routine"><i class="routine"></i></b> <b class="routine"><i class="routine">tgtMemWrite</i></b><b>( )</b>. For more information, see the synopsis of <b class="file">tgtlib</b> in the online reference material under <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Tornado API Reference>Target Server Internal Routines</font></b>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84968">3.6.1 Memory Alignment</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84970"> </a>All memory obtained from the target server's target-memory manager is free from memory alignment problems because the target server memory manager always returns addresses that conform to the target alignment requirements. All <b class="routine"><i class="routine">tgtMem</i></b><i class="textVariable">Xxx</i><b>( )</b><b class="routine"><i class="routine"> </i></b>routines gracefully handle memory alignment.</p><dd><p class="Body"><a name="84972"> </a>However, alignment problems may occur when the object-module headers are processed by the loader. In general, the headers contain data that is <i class="term">packed</i> (without padding) whereas the host architecture may require padding to represent the header information. For example, 16-bit quantities are often enlarged to 32-bit quantities by padding. </p><dd><p class="Body"><a name="84973"> </a>This can cause problems if the object module is not directly processed as a file but rather read entirely into memory first and subsequently processed. This is done to improve performance, but it can also lead to read-word operations at unaligned addresses. Some host architectures accept this, but others do not. Use the <b class="symbol_UC">UNPACK_16</b> and <b class="symbol_UC">UNPACK_32</b> macros (defined in <b class="file">host.h</b>) to prevent portability problems. These macros offer the ability to read 16-bit (or 32-bit) data regardless of the alignment.</p><dd><p class="Body"><a name="84974"> </a>Another kind of alignment problem is related to the three-segment model imposed by the target server loader. In this model, sections of the same type are loaded together within a global area allocated for the coalesced segment. Each section is aligned according to the requirement specified in the object file, or, if none is specified, each is loaded at an address that fits within the target architectures alignment requirement. The requirement specified in the object file cannot be larger than the target alignment requirement. Because of alignment requirements, two coalesced sections may require a "hole" between them (depending on their sizes) to assure proper alignment. Be sure to account for this detail when computing the size of the segment sufficient to hold the coalesced sections. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84975">3.6.2 Target Server Memory Cache</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84977"> </a>The goal of the target server memory cache is to speed up object-module download and minimize the impact of module loading on target performance. It achieves this goal by performing all object-module relocations in host memory and then copying the final relocated module to the target. </p><dd><p class="Body"><a name="84978"> </a>In an ideal world, the target server memory cache would be the same size as the target server memory pool on the target. Then the cache could shadow the entire memory pool. In the real world, the size of the cache is limited by the size of host memory. The default for the target server cache is 1 MB. Use the -<b class="command">m</b> <i class="textVariable">cacheSize</i> option to specify a larger size.</p><dd><p class="Body"><a name="84980"> </a>If the target server memory cache is smaller than the target server memory pool, the first object modules load quickly. However, once the cache is full, each relocation generates a memory-write transaction with the target. This slows the load process, especially if you are using a serial line.</p><dd><p class="Body"><a name="84981"> </a>When the target server memory pool is full and an additional module is loaded, the target server uses <b class="routine"><i class="routine">malloc</i></b><b>( )</b> to request more memory. The target server always requests 1 KB more than it needs in order to limit the number of requests to the target for small chunks of memory.</p><dd><p class="Body"><a name="84984"> </a>Rules for sizing the cache and the target server memory pool:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84985"> </a>Always try to make the target server memory cache large enough to hold all the object modules to be loaded:</li></ul></p><dl class="margin"><dl class="margin"><dd><pre class="Code3"><b><a name="84986">target -m <i class="textVariable">bigEnoughSize</i></a></b></pre></dl></dl><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84987"> </a>If you cannot allocate that much memory, make the cache size as large as your host can accommodate without swapping.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84988"> </a>If possible, install additional memory on the development host.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="84990"> </a>Obtain optimum efficiency by making the <b class="symbol_UC">WDB_POOL_SIZE</b> in <b class="file">config.h</b> at least as large as required to load all the object modules. However, this is not essential since it is extended as necessary on the fly.</li></ul></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84992">3.6.3 Target Virtual Memory and Cache Management</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84993"> </a>Although the loader has memory attributes that can prevent corruption of target memory by the host (<b class="symbol_UC">MEM_NO_WRITE</b>), it cannot prevent the target from corrupting its own memory. Memory on the target side can be protected by the optional product VxVMI, which utilizes the CPU memory management unit (MMU) to designate regions of memory as read-only. The loader has access to this product (if it is installed) through the routine<b class="routine"><i class="routine"> tgtMemProtect</i></b><b>( )</b>. Such protection can be useful when text segments are loaded; they represent program code that must not be corrupted by the execution of another program. </p><dd><p class="Body"><a name="84997"> </a>The target instruction cache, if present, creates problems for the loader if it is not updated when modules are downloaded. If incoherence exists between the instruction cache and the target memory, incorrect instructions can be executed from the cache. To prevent this, the loader updates the target instruction cache by calling<b class="routine"><i class="routine"> tgtCacheTextUpdate</i></b><b>( )</b> each time it loads a module.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84999">3.6.4 Type Abstractions and Address Manipulation</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85001"> </a>Type abstraction is a way to avoid dependencies on the host definition of the size of various types. Tornado uses types with explicit sizes whenever information from the object modules must be manipulated. This information includes, for instance, the header-field contents or any other structural information such as relocation entries.</p><dd><p class="Body"><a name="85002"> </a>Type abstractions can be found in <b class="file">host.h</b> and <b class="file">loadlib.h</b>. </p><dd><p class="Body"><a name="88528"> </a>The type <b class="symbol_lc">void *</b> is used whenever an address is manipulated (through the more convenient type <b class="symbol_UC">SYM_ADRS</b>).</p></dl></dl><a name="foot"><hr></a><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="c-loader.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-loader.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-loader5.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-loader7.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p></body></html><!---by WRS Documentation (), Wind River Systems, Inc. conversion tool: Quadralay WebWorks Publisher 4.0.11 template: CSS Template, Jan 1998 - Jefro --->⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -