📄 c-loader5.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-loader4.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-loader6.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="84577">3.5 Loader Architecture</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84579"> </a>The loader has a three-layered structure. At the generic level is a library of routines that are common to all configurations. At the object-module format level are several OMF managers to handle different object-module formats. At the architecture level are several RUs (relocation units), each supporting a specific architecture. <a href="c-loader5.html#84586">Figure 3-1</a> illustrates the relationship between the three levels. <div class="frame"><h4 class="EntityTitle"><a name="84586"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 3-1: Target Server Loader Architecture</font></a></h4><dl class="margin"><div class="Anchor"><a name="84652"> </a><img class="figure" border="0" src="images/c-loader0.gif"></div></dl></div> </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84654">3.5.1 Object-Module Configuration in Target Memory</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84656"> </a>Since the object-file sections hold a program (a set of routines), and since this set of routines must be installed in the real target memory, there is a strong relationship between section configuration in the file and in the target memory. How the loader locates the sections in memory depends on whether the file type is relocatable or fully linked.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84657">Relocatable Files </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84659"> </a>The loader uses a three-segment model for loading relocatable modules. It coalesces the module sections into three segments in target memory: a text segment, a data segment, and a <i class="term">bss</i> segment. It combines sections of the same or compatible type into one segment (see <a href="c-loader5.html#84666">Figure 3-2</a>). Note that the order of coalescence is strictly the order in which the text and literal sections exist in the file.<div class="frame"><h4 class="EntityTitle"><a name="84666"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 3-2: Section Combination in Relocatable Files</font></a></h4><dl class="margin"><div class="Anchor"><a name="84711"> </a><img class="figure" border="0" src="images/c-loadera1.gif"></div></dl></div></p><dd><p class="Body"><a name="84712"> </a>Because the loader creates only three segments, it handles literal sections in the same way as text sections. If literal sections are present in a relocatable object module, the loader coalesces them with the text sections. The sections are similar in that contents of both types of sections must not be modified while the program is executing.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="88554"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>The RU also treats other constant data sections, such as ELF <b class="symbol_lc">.rodata</b> sections, as literal sections and coalesces them into the data segment.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84723">Fully Linked Files</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84725"> </a>The loader retains the file configuration for fully linked files. Each section is represented separately in target memory. This allows an application to take advantage of a target system with non-contiguous RAM or with high-speed static RAM and dynamic RAM.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84728">3.5.2 Module Management</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84730"> </a>The generic module management library keeps track of what modules have been loaded in memory, where their segments are, how much memory they use, and which symbols belong to which modules.</p><dd><p class="Body"><a name="84732"> </a>During loading, a temporary data structure, <b class="symbol_UC">SEG_INFO</b>, describes the contents of an object module. The <b class="symbol_UC">SEG_INFO</b> structure contains the following elements:</p></dl><dl class="margin"><ul class="DashSingle" type="circle"><li><a name="84733"> </a>the text segment address</li></ul><ul class="DashSingle" type="circle"><li><a name="84734"> </a>the data segment address</li></ul><ul class="DashSingle" type="circle"><li><a name="84735"> </a>the <i class="term">bss </i>segment address</li></ul><ul class="DashSingle" type="circle"><li><a name="84736"> </a>the text segment size</li></ul><ul class="DashSingle" type="circle"><li><a name="84737"> </a>the size of the text segment that is write-protected (if any)</li></ul><ul class="DashSingle" type="circle"><li><a name="84738"> </a>the data segment size</li></ul><ul class="DashSingle" type="circle"><li><a name="84739"> </a>the <i class="term">bss </i>segment size</li></ul><ul class="DashSingle" type="circle"><li><a name="84740"> </a>the text segment option for memory management</li></ul><ul class="DashSingle" type="circle"><li><a name="84741"> </a>the data segment option for memory management</li></ul><ul class="DashSingle" type="circle"><li><a name="84742"> </a>the <i class="term">bss </i>segment option for memory management</li></ul></dl><dl class="margin"><dd><p class="Body"><a name="84743"> </a>When the loader finishes loading the object module, it transfers the <b class="symbol_UC">SEG_INFO</b> contents to a more permanent representation. Each module representation is a member of a linked list and is located by means of a <b class="symbol_UC">MODULE_ID</b> handle. The module representation contains the following information:</p></dl><dl class="margin"><ul class="DashSingle" type="circle"><li><a name="84745"> </a>the name of the object file</li></ul><ul class="DashSingle" type="circle"><li><a name="84746"> </a>the symbol group number</li></ul><ul class="DashSingle" type="circle"><li><a name="84747"> </a>the format of the object module (a.out, COFF, ELF, and so on)</li></ul><ul class="DashSingle" type="circle"><li><a name="84748"> </a>the target CPU type</li></ul><ul class="DashSingle" type="circle"><li><a name="84749"> </a>the loader options (also known as load flags)</li></ul><ul class="DashSingle" type="circle"><li><a name="84750"> </a>a list of the object-module undefined symbols (if any)</li></ul><ul class="DashSingle" type="circle"><li><a name="84751"> </a>a linked list of the object-module segments</li></ul></dl><dl class="margin"><dd><p class="Body"><a name="84752"> </a>Each segment in the linked list has a representation that contains:</p></dl><dl class="margin"><ul class="DashSingle" type="circle"><li><a name="84753"> </a>the segment address</li></ul><ul class="DashSingle" type="circle"><li><a name="84754"> </a>the segment size</li></ul><ul class="DashSingle" type="circle"><li><a name="84755"> </a>the segment type (text, data, or bss)</li></ul><ul class="DashSingle" type="circle"><li><a name="84756"> </a>the memory management information</li></ul><ul class="DashSingle" type="circle"><li><a name="84757"> </a>the segment checksum</li></ul></dl><dl class="margin"><dd><p class="Body"><a name="84758"> </a>Type definitions for both <b class="symbol_UC">MODULE_ID</b> and <b class="symbol_UC">SEG_INFO</b> are in <b class="file">module.h</b>.</p><dd><p class="Body"><a name="84760"> </a>The ability to unload a module is an important outgrowth of module management. Unloading a module implies freeing the memory associated with the module segments and removing the module symbols from the target server symbol table.</p><dd><p class="Body"><a name="84761"> </a>When creating a new OMF manager, you can use the code from existing loaders as a model for providing module management. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84764">3.5.3 Symbol Management</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84766"> </a>The loader processes the object-module symbols by reading the file symbol table. Part of this processing is required for relocation. Additional processing is necessary to add the module symbols to the target server symbol table.</p><dd><p class="Body"><a name="84768"> </a>The target server symbol table holds all the symbols related to the remote system, including symbols from the target agent and symbols from dynamically loaded user modules. Maintaining this table within the target server on the host saves memory on the target and gives host tools access to all public symbols (and local symbols, if desired) that are present on the target system. The target server symbol table holds one entry per symbol, with the following information:</p></dl><dl class="margin"><ul class="DashSingle" type="circle"><li><a name="84769"> </a>the name of the symbol</li></ul><ul class="DashSingle" type="circle"><li><a name="84770"> </a>the address of the symbol</li></ul><ul class="DashSingle" type="circle"><li><a name="84771"> </a>the segment type of the symbol (text, data, or <i class="acronym_lc">bss</i>)</li></ul><ul class="DashSingle" type="circle"><li><a name="84772"> </a>the object-file name from which the symbol comes</li></ul></dl><dl class="margin"><dd><p class="Body"><a name="84773"> </a>The target server symbol table is filled at target server start-up time with the core-file symbol table. (For more information on this process, see <a href="c-loader3.html#84452"><i class="title">Bootstrapping the Target Server Symbol Table</i></a>.)</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84777">Symbol Processing</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84779"> </a>When a relocatable file is loaded, its symbol table is analyzed and the symbols are processed depending on the categories they belong to:</p></dl><dl class="margin"><b class="HU-bullet"><li><a name="84781"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Defined Symbols</b></font></font></li></b></dl><dl class="margin"><dd><p class="Body"><a name="84782"> </a>These symbols refer to objects (routines, variables, or constants) that are present in the module text, data, or <i class="term">bss </i>segments. They may be static (their scope limited to the module itself) or global (accessible to objects outside the module). Defined symbols need no relocation and may be added directly to the target server symbol table if desired.</p></dl><dl class="margin"><b class="HU-bullet"><li><a name="84784"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Undefined Symbols</b></font></font></li></b></dl><dl class="margin"><dd><p class="Body"><a name="84785"> </a>These symbols are referred to in the module text or data but are not present in the module. They must be global. For such symbols, the loader must locate the symbol in the target server symbol table in order to relocate the module. If the symbol is not found, it is considered <i class="emphasis">unknown </i>and<i class="emphasis"> </i>its name is added to a list that is returned to the tool requesting the load. </p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/warning.gif"></td><td><hr><div class="CalloutCell"><a name="88570"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">WARNING: </font></b></a>While a module containing undefined symbols is downloaded anyway, the consequence is that the module may be partly or totally unusable since no relocation can be done on the unknown symbols. This partial linkage permits testing pieces of an application during development as long as the tested pieces do not hold references to undefined symbols.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout><dl class="margin"><b class="HU-bullet"><li><a name="84797"> </a><font face="Helvetica, sans-serif" size="-1" class="sans"><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb">Common Symbols</b></font></font></li></b></dl><dl class="margin"><dd><p class="Body"><a name="84798"> </a>These symbols are handled as a special case. Consider the example below: </p></dl><dl class="margin"><dd><pre class="Code"><b><a name="84799"> #include <stdio.h> int willBeCommon; void main (void) {} { ... }</a></b></pre></dl><dl class="margin"><dd><p class="Body"><a name="84807"> </a>The symbol willBeCommon is uninitialized, so it is technically an undefined symbol. Such a definition becomes <i class="term">common</i>. ANSI C allows multiple files to use uninitialized symbols to refer to the same variable and expects the loader to resolve these references consistently. </p><dd><p class="Body"><a name="84808"> </a>It is often helpful in an incremental environment to be able to share a symbol among several files and to load the files in any order; however, it is also extremely risky to treat common variables in this way. When linked, a common definition could resolve to any defined symbol in the symbol table depending on what symbols are defined in already-loaded modules. The default for Tornado treats common symbols as undefined. However, you can set the loader options to permit common symbols to be loaded; then only the first instance of the symbol will be added to the symbol table and other instances will use the same address. For more information, see <a href="c-loader5.html#84852"><i class="title">3.5.4 Loader Options</i></a>.</p></dl><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="88587"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a><i class="term">External symbols</i><font face="Helvetica, sans-serif" size="-1" class="sans"><b class="hb"> </b></font>are <i class="term">public</i> (visible to everyone both within and outside the file that declares them). The term <i class="term">external</i> is not used in this document to mean "declared outside the file" (as opposed to "declared inside the file").</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84822">Symbol Type Definitions</a></i></h5>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -