[Contents][Index][Top][Prev][Next]

1.3   The Target Server and the WTX Protocol

Target servers run on Tornado host systems. Each target server represents one development target. All tools access a target through its server, whose responsibility is to satisfy each tool's requests for target actions or target information. The target server manages all of the details of communicating with the target, so that tools are not concerned themselves with host-target transport details. Tornado tools use the WTX protocol to communicate with a target server.

In some cases, a request from a Tornado tool is passed directly to the WDB agent for execution on the target system. In other cases, requests can be managed entirely within the target server. For example, the target server caches recently-used regions of memory. This enables the target server to respond directly when a target-memory read hits a memory region that is already cached in the target server, thereby avoiding the need for an actual host-target transaction.

The target server architecture is shown schematically in Figure 1-2. and outlined in the following paragraphs.

Figure 1-2:  Target Server Architecture

  • WTX Protocol Dispatch.  
    The "front end" of the target server, this layer connects to Tornado tools, receives protocol requests and prepares replies, in the meantime calling target server subroutines to provide the services required.

  • Target Server Core.  
    The target server core contains the interpreter for the WTX protocol. It is here that the target server determines what services to perform locally on the host, and what services to pass along to the back end to transmit to the target. WTX services that can be carried out entirely in the target server are implemented in the target server core; general-purpose callbacks used by other parts of the target server also reside here.

  • Target Symbol Table.  
    The target server uses the symbol list contained in every object module to build a host-resident symbol table representing all loaded functions and variable names on the target system. Names from system and application modules alike are included in the target symbol table. The object module loader uses the symbol table to resolve external references and relocate symbolic references. Tornado tools can also manipulate the symbol table through WTX requests.

  • Object Loader/Unloader.  
    Central to the Tornado architecture is its ability to incrementally load object modules into the target system. Because modules can be loaded dynamically, development cycles are much shorter: when a developer changes a particular feature, only the affected module needs to be recompiled and reloaded, not the entire application. The loader uses the system symbol table to resolve undefined references in modules being loaded, dynamically linking newly loaded modules to previously loaded modules.

    In addition, the target server provides the ability to unload modules from the system. When a module is removed, all the associated symbols are removed from the symbol table and memory is reclaimed.

  • OMF Readers.  
    Object modules come in many formats. The target server utilizes shared libraries on UNIX hosts and dynamically linked libraries (DLLs) on Windows hosts to isolate the OMF reader from the target server core. This makes it simple to add new object module formats without requiring a new release of the target server.

  • Target Memory Manager.  
    The loader requires memory from the target pool when allocating space for the linked module, and host-resident Tornado tools, such as the shell or debugger, also use some target memory as a working area. Rather than call upon the target to manage a pool of memory on the host tools' behalf, the target server manages a pool of target memory for all allocation requests originating on the host. The target memory manager maintains all bookkeeping structures (such as a free block list and block headers) on the host, and thus provides zero-overhead target memory allocation. When a tool asks for 24 bytes, it receives exactly 24 bytes of target memory (subject to alignment). The size of the pool managed by the target server is configured at target start-up time, but it can increase dynamically.

  • Target Memory Cache.  
    Some regions of target memory are good candidates for caching. The target memory cache, by default, caches the program text sections of all target-resident modules. Because it is highly unorthodox to modify the text of the program (beyond adding breakpoints), this use of the cache provides a considerable boost in performance for cross-debugging.

  • Target Server disassembler.  
    Your WTX application can call on the target server to disassemble a region of target memory. The target server disassembly facility differs from GDB disassembly in that it produces chip-manufacturer standard output instead of FSF standard output. The disassembler for each chip resides in its own shared library which is dynamically linked when the target server attaches to the target.

  • Target Server File System.  
    The Target Server File System (TSFS) is a full-featured VxWorks file system, but the files operated on by using the file system are actually located on the host. TSFS uses a WDB driver to transfer requests from the I/O system to the target server. The target server reads the request and executes it using the host file system and the host-target communication path. It is possible to access host files randomly without copying the entire file to the target, to load an object module from a virtual file source, to supply the file name to routines such as ld( )and copy( ), and even to open a socket without installing the TCP/IP stack on the target.

  • Back-End Manager.  
    Perhaps one of the most convenient aspects of the target server is its handling of the drudgery associated with managing a host-target connection mechanism. The back-end manager maps a transport-independent layer of subroutine calls, used by the rest of the target server, into the appropriate transport-dependent calls for a particular back end.

    In some cases, certain back-end requests have no direct mapping to a particular back end. For instance, it is unlikely that an emulator can support the parsing of a Gopher script. In this case the back-end manager decomposes the request into more easily mapped target-memory reads. Likewise, the back-end manager behaves correctly in response to the inability of a back end to perform some types of breakpoint strategies. By virtue of Tornado's back-end management, tool providers can concentrate on enhanced functionality instead of porting to yet another connection strategy.

  • Target Server Back End.  
    Whether it is as simple as an Ethernet connection, or as complicated as an emulator connection, the target server back end does whatever is required to communicate a WDB request to the target agent. As with the OMF readers, the target server back ends are organized as shared libraries on UNIX hosts, and as DLLs on Windows hosts. This allows introducing a new connection mechanism at any time.

    • [Contents][Index][Top][Prev][Next]