⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 c-bkend1.html

📁 vxworks相关论文
💻 HTML
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title>    Target Server Back End    </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-bkend.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-bkend.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-bkend.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-bkend2.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="84386">2.1  &nbsp;&nbsp;Introduction</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84388"> </a>The target server acts as a broker for the communication path to the target and provides services commonly required by the Tornado tools. In order to support new CPU architectures, new object-module formats, and new communications back ends with minimum programming effort, the corresponding parts of the target server are structured as shared libraries on UNIX or dynamically linked libraries (DLLs) on Windows.<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup> The remainder of the target server, known as the target server core, is independent of the target architecture, the target operating system, and of the communications transport layer.</p><dd><p class="Body"><a name="84393"> </a>This chapter examines the communications back end. It shows how a back end fits into the architecture of the target server, how the back end is implemented in Tornado, and how to implement new back ends, either for the WDB agent or for non-WDB agents such as emulators. For an overview of the target server and its components, see <a href="c-overview3.html#84473"><i class="title">1.3&nbsp;The Target Server and the WTX Protocol</i></a>. To add a new object-module-format loader, see <a href="c-loader.html#84380"><i class="title">3.&nbsp;Object-Module Loader</i></a>. This chapter gives an overall orientation; for details, see the online reference material under <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Tornado API Reference&gt;Target Server Back End Interface</font></b>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84403">2.1.1  &nbsp;&nbsp;Target Server Overview</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84405"> </a>A target server session typically involves the following activities:</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84406">Initializing the Target Server</a></i></h5></font><dl class="margin"><p><ol class="List"><li value="1."><a name="84408"> </a>The target server is invoked with the following syntax:</li></ol></p><dl class="margin"><dd><div class="Item2"><a name="89609"> </a>UNIX: </div><dl class="margin"><dd><pre class="Code3"><b><a name="84409"></b><tt class="output">%</tt><b> tgtsvr -V -B mybkend ... &amp;</a></b></pre></dl><dd><div class="Item2"><a name="89611"> </a>Windows: </div><dl class="margin"><dd><pre class="Code3"><b><a name="89610"></b><tt class="output">c:&gt; </tt><b>tgtsvr -V -B mybkend ...</a></b></pre></dl></dl><dl class="margin"><dd><div class="Indent"><a name="84411"> </a>where <b>-V</b> enables verbose diagnostic messages and <b>-B</b> specifies the back end.</div><br></dl><p><ol class="List"><li value="2."><a name="84412"> </a>The target server loads the back-end DLL specified with the <b>-B</b> parameter. (In the example, the back end is named <b>mybkend</b>; in the discussion, replace <b>mybkend</b> with the name of the back end you are developing.) The target server asks the back end if it can be customized through special command-line arguments. </li></ol></p><p><ol class="List"><li value="3."><a name="84413"> </a>If so, the target server parses its command-line argument and feeds the information to the back end.</li></ol></p><p><ol class="List"><li value="4."><a name="84415"> </a>Next, the target server registers itself with the registry, <b class="operator">wtxregd</b>, so that tools can connect to it.</li></ol></p><p><ol class="List"><li value="5."><a name="84416"> </a>The target server initializes the back end by calling a function named <b class="routine"><i class="routine">mybkendInitialize</i></b><b>(&nbsp;)</b> in the DLL. Every back end must provide an initialization routine which has the name of the back end followed by <b class="routine"><i class="routine">Initialize</i></b>. The routine <b class="routine"><i class="routine">mybkendInitialize</i></b><b>(&nbsp;)</b> initializes the back end, fills in a <b class="symbol_UC">TGT_OPS</b> structure with the address of each back end function, and a<b class="symbol_UC"> BKEND_INFO</b> structure with the method chosen to alert the target server when events come to the back end. The <b class="symbol_UC">TGT_OPS</b> structure is defined in <i class="textVariable">installDir</i><b class="symbol_UC">/</b><b class="file">host/include/host.h</b> and the <b class="symbol_UC">BKEND_INFO</b> structure is defined in <i class="textVariable">installDir</i><b class="file">/host/include/bkendlib.h</b>.</li></ol></p><p><ol class="List"><li value="6."><a name="84417"> </a>The target server connects the back end to the target by calling the back-end target-connect function.</li></ol></p><p><ol class="List"><li value="7."><a name="84418"> </a>Finally, the target server performs other initialization, such as loading the OMF reader and reading the symbols in the OS core file.</li></ol></p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84419">Servicing Tool Requests</a></i></h5></font><dl class="margin"><p><ol class="List"><li value="1."><a name="84421"> </a>The target server launches a thread to wait for WTX protocol requests sent by tools and another to wait for target events. Whenever a target event occurs, the back end notifies the target server using the method specified in <b class="symbol_UC">BKEND_INFO</b>. The target server then queries the back end for information about the event and notifies the tools that have registered to receive notification of the event.</li></ol></p><p><ol class="List"><li value="2."><a name="84422"> </a>If a tool makes a request, the target server either satisfies the request itself (for example, by looking up a symbol in the host-resident symbol table) or forwards the request to the back end (for example, by requesting that the back end set a breakpoint or read memory).</li></ol></p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84425">Shutting Down the Target Server</a></i></h5></font><dl class="margin"><p><ol class="List"><li value="1."><a name="84427"> </a>When the target server exits, it calls the back-end disconnect routine to clean up all resources that have been allocated by the back end.</li></ol></p><p><ol class="List"><li value="2."><a name="84429"> </a>Next, the target server disconnects all tools and removes its name from the Tornado registry (wtxregd).</li></ol></p><p><ol class="List"><li value="3."><a name="84431"> </a>Finally, the target server exits.</li></ol></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="84432">2.1.2  &nbsp;&nbsp;Back-End Overview</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84433"> </a>The portion of the Tornado target server that communicates with the target is called the <i class="term">back end</i>. Many back ends are supported, each dedicated to an alternative host-target connection. All back ends share a single purpose: to provide a set of primitive services for the target server core. Depending on the back end, executing these routines can be as simple as forwarding a request to the target agent (the <b class="command">WDB RPC</b> back end) or as complex as translating the request to an entirely different protocol (an emulator back end).</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84435">WDB Back Ends</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84437"> </a>Some back ends (<i class="term">WDB back ends</i>) are designed to communicate with the target agent supplied with VxWorks, which is called the <i class="term">WDB agent</i>. (See <a href="c-bkend1.html#90230">Figure&nbsp;2-1</a>.) The WDB agent uses the Wind DeBug (WDB) protocol to communicate between the host and target operating system. The key advantage of this protocol, from a programming perspective, is that it corresponds one-to-one with the target server back-end API. There is a back-end function corresponding to each WDB protocol request. When using the WDB agent, the back end manages the mechanics of transmitting the request to the target over whatever hardware medium provides host-target communication. Creating a new back end is a matter of writing the necessary host and target code to transport WDB protocol messages.<sup><a href="#foot"><b class="FootnoteMarker">2</b></a></sup>&nbsp;<div class="frame"><h4 class="EntityTitle"><a name="90230"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-1:&nbsp;&nbsp;WDB Back End</font></a></h4><dl class="margin"><div class="Anchor"><a name="90232"> </a><img class="figure" border="0" src="images/c-bkend7.gif"></div></dl></div>&nbsp;&nbsp;</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84495">Non-WDB Back Ends</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84497"> </a>Other back ends (<i class="term">non-WDB back ends</i>) are designed to communicate with alternative agents, such as an emulator that serves as a hardware debug agent. (See <a href="c-bkend1.html#90293">Figure&nbsp;2-2</a>). If a back end does not use the WDB agent, the back end itself must provide the requested service. The underlying service could be provided by another software agent (for example, a ROM monitor) or by a hardware agent (for example, an in-circuit emulator or ICE). Virtually any cross-development framework can be supported in a back end because the back-end API is general. It is also possible, if necessary, to return a "service not available" error or to fill in the <b class="symbol_UC">TGT_OPS</b> table with a <b class="symbol_UC">NULL</b> pointer if it is impossible to implement the service as requested by the target server.&nbsp;<div class="frame"><h4 class="EntityTitle"><a name="90293"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-2:&nbsp;&nbsp;Non-WDB Back End</font></a></h4><dl class="margin"><div class="Anchor"><a name="90295"> </a><img class="figure" border="0" src="images/c-bkend0.gif"></div></dl></div>&nbsp;&nbsp;</p><dd><p class="Body"><a name="84557"> </a>This chapter provides background information on the structure of a target server back end, followed by descriptions of how to write new back ends for the WDB agent and for a non-WDB agent. Writing a new back end allows you to use a different communication protocol or to use a new method for providing services to the Tornado tools; none of the tools needs to be modified because the tools communicate only with the target server. Our discussion provides an overall orientation; throughout this chapter, refer to the reference entries in Part 2 for details. </p></dl></dl><a name="foot"><hr></a><p class="FootnoteNumberMarker">1:&nbsp;<span class="Footnote"><a name="84392"> </a>The Tornado implementation is designed to work in both UNIX and Windows environments; thus, in most cases the terms can be used interchangeably. In this chapter, <i class="term">DLL</i> refers to both Windows DLLs and UNIX shared libraries unless an explicit distinction is made.</span><p class="FootnoteNumberMarker">2:&nbsp;<span class="Footnote"><a name="84444"> </a>The current implementation of this protocol is based on Sun Microsystems RPC 4.0, which can be implemented on virtually any transport layer.</span><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="c-bkend.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-bkend.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-bkend.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-bkend2.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 + -