📄 c-bkend4.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-bkend3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-loader.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="85474">2.4 Writing a Non-WDB Back End</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85476"> </a>This section addresses the task of writing a back end that communicates with an agent (such as an emulator) other than the WDB agent. In this case, your back end methods must service back-end API requests directly, in other words, by way of a proprietary emulator API. For a general approach highlighting some of the issues involved in this process, see <a href="c-bkend4.html#85481"><i class="title">2.4.1 Overview of Writing a Non-WDB Back End</i></a>. The remainder of this chapter presents an example implementation. The complete source code for the <b class="keyword">acecpu32</b> example back end plus a back-end development class library, which implements the back-end framework as a C++ abstract base class, are provided in the<i class="term"> Back-End Developer's Kit</i>. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85481">2.4.1 Overview of Writing a Non-WDB Back End</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85483"> </a>The following tasks are involved in writing a non-WDB back end:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85484"> </a>writing the initialization routine</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85485"> </a>writing the back-end methods to provide basic run control</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85486"> </a>adding advanced features (such as target function invocations)</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85487"> </a>testing the back end</li></ul></p></dl><dl class="margin"><dd><p class="Body"><a name="85488"> </a>The initialization routine is the entry point of the back end. It performs the back-end initialization and attachment. Even before the rest of the back-end functions are implemented, this routine can be called to test correct attachment between the back end and the target server. </p><dd><p class="Body"><a name="85489"> </a>Once the attachment and initialization procedures have been carried out successfully, you are ready to begin the major task of writing, documenting, and testing the back-end functions. The remainder of this section outlines the key development issues and suggests one approach to implementing a back end.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85490">Design</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85492"> </a>The first step in your implementation is to determine what functions your back end must provide. The easiest way to establish this is by using the <i class="title">Back-End Developer's Kit</i> as a basis. It contains a sample back end, the <b class="keyword">acecpu32</b>, which is an implementation for the fictitious ACE C API. It operates an emulator supporting Motorola CPU32 microprocessors through BDM. It provides a structure and an implementation of common back-end services, including Gopher and checksum, which are emulator independent. You will need to support memory and register accesses, event handling on the target, communication with the emulator or other agent, state handling, and other emulator-dependent services.</p><dd><p class="Body"><a name="85542"> </a><a href="c-bkend4.html#85502">Figure 2-7</a> shows the structure of the <b class="keyword">acecpu32</b> implementation. <div class="frame"><h4 class="EntityTitle"><a name="85502"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-7: acecpu32 Implementation</font></a></h4><dl class="margin"><div class="Anchor"><a name="85541"> </a><img class="figure" border="0" src="images/c-bkend9.gif"></div></dl></div></p><dd><p class="Body"><a name="85546"> </a><a href="c-bkend4.html#85551">Figure 2-8</a> shows how the <b class="symbol_lc">Event_T</b> class, which manages target event information, is implemented to queue <b class="symbol_UC">WDB_EVT_DATA</b>. <div class="frame"><h4 class="EntityTitle"><a name="85551"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-8: Event Queue Structure</font></a></h4><dl class="margin"><div class="Anchor"><a name="85576"> </a><img class="figure" border="0" src="images/c-bkenda1.gif"></div></dl></div></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85578">Implementation</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85580"> </a>The recommended plan for implementing the back end is to add support incrementally for the desired services, exercising them with the <b class="keyword">wtxtcl</b> shell at each stage. (For more information on <b class="keyword">wtxtcl</b>, see <a href="c-wtx4.html#85250"><i class="title">4.4 WTX Tcl API</i></a>.) Initially, you should write enough of the framework so that the target server can load your skeleton back end. Then you can add the key functions, testing them to make sure that you are on the right track. If you plan to support both UNIX and Windows hosts, we recommend that you build and test on both hosts in parallel.</p></dl><dl class="margin"><p><ol class="List"><li value="1."><a name="85585"> </a>First, create a directory in <i class="textVariable">installDir</i><b class="file">/host/src/tgtsvr/backend</b> for the back end. By convention, the name of the back end and its directory should be a short, descriptive phrase which is all lower-case, such as <b class="keyword">acecpu32</b>, for the ACE CPU32 emulator back end.</li></ol></p><p><ol class="List"><li value="2."><a name="85586"> </a>Next, implement a skeleton back-end module which initializes the back end. The module must contain the back-end initialization routine and any other necessary routines. The target server will call the initialization routine when it loads the back end. You may find it helpful to provide stubs for other functions which log an error message to the console. Then you can start the target server with your back end and use the <b class="keyword">wtxtcl</b> shell to test that it invokes functions in response to WTX requests.</li></ol></p><p><ol class="List"><li value="3."><a name="85587"> </a>Implement the functions to read and write memory and registers.</li></ol></p><p><ol class="List"><li value="4."><a name="85588"> </a>Implement the functions to set breakpoints, stop execution, resume execution, and step a context.</li></ol></p><p><ol class="List"><li value="5."><a name="85589"> </a>Add event handling. At this point you should be able to get CrossWind, the source-level debugger, to operate successfully.</li></ol></p><p><ol class="List"><li value="6."><a name="85590"> </a>Implement desired optional functions, such as the ability to invoke functions on the target.</li></ol></p><p><ol class="List"><li value="7."><a name="85591"> </a>Tune performance. If you can optimize memory and register reads, you can improve performance significantly. </li></ol></p></dl><dl class="margin"><dd><p class="Body"><a name="85592"> </a>By implementing the back-end functions in this order, you will be able to verify quickly that different layers of the Tornado development environment interface correctly with your back end and the emulator you are supporting.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85594">Wind River Conventions</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85596"> </a>The interface between the target server and the back end is documented in <a href="c-bkend2.html#84559"><i class="title">2.2 Back-End Implementation</i></a>. In addition, <a href="c-bkend2.html#84567"><i class="title">2.2.1 Attachment and Initialization</i></a> describes the WDB data structures used to pass information into and out of the back end. Your back end methods must also use the WDB error codes. Both the error codes and the data structures are declared in <i class="textVariable">installDir</i><b class="file">/share/src/agents/wdb/wdb.h</b>. </p><dd><p class="Body"><a name="85603"> </a>The Wind River C coding conventions are documented in the <i class="title">Tornado User's Guide: C and C++ Coding Conventions</i>. The following additional conventions have been adopted for C++ and the <i class="title">Back-End Developer's Kit</i>:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85604"> </a>Class names end with <b class="symbol_lc">_T</b>.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85605"> </a>Member function names end with <b class="symbol_lc">_m</b>.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85606"> </a>Member data names end with <b class="symbol_lc">_</b>.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85607"> </a>Static member function names end with <b class="symbol_lc">_s</b>.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85608"> </a>Wind River C conventions for naming and indentation.</li></ul></p></dl><dl class="margin"><dd><p class="Body"><a name="85609"> </a>Finally, we recommend that you do not use C++ static objects in the back end because you will have no control over when their constructors and destructors are called. Instead, manage the objects with <b class="symbol_lc">new</b> and <b class="symbol_lc">delete</b>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85610">Testing</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85613"> </a>Back-end testing relies on the <b class="keyword">wtxtcl</b> shell provided with Tornado. This shell allows you to send WTX protocol requests to the target server, the same kinds of requests the tools send. Using <b class="keyword">wtxtcl</b>, you can interactively invoke the back-end methods to verify that they work correctly. Program <b class="keyword">wtxtcl</b> in Tcl, which Wind River has extended to support the WTX protocol. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85614">2.4.2 Setting Up the Back-End Developer's Kit</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85616"> </a>This section and the two sections that follow it use the libraries and methods of the <i class="title">Back-End Developer's Kit </i>as an example implementation for the CPU32 emulator. You may be able to use significant portions of this framework for your back end.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85617">Design Considerations</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="87909"> </a>The<i class="title"> Back-End Developer's Kit</i> consists of a class library that provides the basic back-end framework, an example back end for <b class="keyword">acecpu32</b>, sample test scripts, and this document. The library also implements common back-end methods, including Gopher and checksum, which are emulator-independent. By integrating this back-end framework into a new back end, you will not have to spend time developing and debugging these back-end services. To take advantage of this framework, derive a vendor-specific back-end class from the abstract base class <b class="symbol_lc">Backend_T</b>, declared in <b class="file">backend.h</b> as shown in the following example:</p><dl class="margin"><dd><pre class="Code2"><b><a name="87913">... #include "backend.h" ... // Declaration of Vendor-specific back end class class Ace_T : public Backend_T { // Backend_T methods which you are overriding go here ... // Your vendor-specific methods and data go here };</a></b></pre></dl><dd><p class="Body"><a name="87914"> </a>Once you have derived your vendor-specific class, determine what other classes and objects you need in your system. If you are integrating an existing C API for operating the emulator, you may find that the <b>acecpu32</b> example back end can be modified. </p><dd><p class="Body"><a name="85635"> </a>Some of the classes and objects you may need include the following:</p></dl><dl class="margin"><ul class="DashSingle" type="circle"><li><a name="85636"> </a>an event class for handling events on the target</li></ul><ul class="DashSingle" type="circle"><li><a name="85637"> </a>a communication object to communicate with the emulator</li></ul><ul class="DashSingle" type="circle"><li><a name="85638"> </a>an object for handling state</li></ul><ul class="DashSingle" type="circle"><li><a name="85639"> </a>a parsing object to operate an emulator's ASCII interface if there is no binary interface</li></ul></dl><dl class="margin"><dd><p class="Body"><a name="85688"> </a><a href="c-bkend4.html#85647">Figure 2-9</a> shows the architecture of the <b class="keyword">acecpu32</b> back end. <div class="frame"><h4 class="EntityTitle"><a name="85647"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-9: acecpu32 Architecture</font></a></h4><dl class="margin"><div class="Anchor"><a name="85687"> </a><img class="figure" border="0" src="images/c-bkenda2.gif"></div></dl></div> </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85689">Implementation</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85691"> </a>After installing the libraries supplied with the <i class="term">Back-End Developer's Kit</i>, follow the implementation procedure laid out in <a href="c-bkend4.html#85481"><i class="title">2.4.1 Overview of Writing a Non-WDB Back End</i></a>. When you begin tuning performance, if your emulator can perform an operation more efficiently than the default implementation (for example, a memory scan) override <b class="symbol_lc">Backend_T</b>'s methods.</p><dd><p class="Body"><a name="85695"> </a>For an example of how to use WDB data structures and error codes, look at the <b class="keyword">acecpu32</b> example code in <i class="textVariable">installDir</i><b class="file">/host/src/tgtsvr/backend/acecpu32</b>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85696">Porting</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85697"> </a>The <i class="title">Back-End Developer's Kit's</i> class library is supported only on Solaris 2.5.1 and 2.6, Windows NT, and Windows 95 hosts. The source code for this library is provided and can be readily ported to other hosts because of the limited use of operating system calls. Furthermore, the Tornado development environment provides generic makefile stubs which abstract most of the host-dependent build issues.</p></dl></dl>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -