Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Preventing errors by testing or debugging software
  • G06F11/3664—Environments for testing or debugging software

Definitions

• This application claims priority of U.S. Provisional Patent Application No. 60/005,110, filed September 1, 1995, entitled “A Tool for Software Diagnosis Divided Across Multiple Processors,” with Attorney Docket No. 014274-000200.
• This invention relates to software development and debugging environments.
• the invention relates to development and debugging environments wherein the software to be analyzed resides in a processor system distinct from but connected to another processor system running the debugging software's interface with the user.
• debugger In the development of software, the use of a debugging program (or "debugger") is not uncommon to analyze software to be developed or known to have a bug. This is the test software.
• One of the primary functions of such a debugger is to allow the user — typically a development or diagnostics engineer — to view the memory as modified by the execution of the test software.
• the problems of debugging software are amplified in certain respects when the processor system on which the test software resides (the "target system” or “target”) has insufficient resources to support a debugging environment.
• the usual critical resource is memory.
• a substantial portion of the debugging environment can be displaced to a separate remote system, the "host system” or “host,” and the target and host systems communicate by a communications link.
• the software on the target communicating over the link is the debugging agent, and that portion residing on the host is the debugging server.
• the resolution of the limited memory problem by displacement results in other problems: communicating using the limited bandwidth of the communications link, for example.
• the bandwidth limitation is particularly acute when mass or high-speed data throughput is not the primary function of what becomes the communications link for development or debugging purposes or when complex and/or large data structures such as linked lists or tables must be retrieved by the debugging server from the debugging agent.
• a significant portion of the bandwidth expended on retrieval of data from the target is simply the transmission of data requests from the server to the agent. For example, the retrieval of the linked list linked_data_list of the following data structure
• the uploading of data to the host computer can consume a major percentage of the available bandwidth on the communications link.
• the debugging server lacks the intelligence to ask whether the data being transferred is duplicative or otherwise unnecessary. Accordingly, there is a need for a debugging server which screens requests for data of the target and thereby reduces the amount of traffic on the communications link. There is also a need for a debugging server to screen data destined for the target and thereby reduce the amount of traffic on the communications link.
• Some systems do not incorporate any means for communicating with the external world during normal operation. Nonetheless, a developer would like to debug in situ these and other similarly situated systems (e.g. , systems where interrupting (any of) the fully allocated communications interface (s) is not preferable). A technique to enable the developer to debug these severely resource-limited systems is needed.
• an object of this invention is to create a debugging environment which has a smaller footprint in the memory of target systems.
• Another object of the invention is to minimize the size of the debugging agent in the target memory while still offering all of the capabilities a software developer expects from a full-featured debugging environment.
• An object of the invention is the addition of intelligence to the host-side software in order to reduce the consumption of available bandwidth by reducing both the number and size of target/host transactions.
• Another goal of the invention is the addition of intelligence to the host-side software in order to obviate certain target-side intelligence and thus free the memory the target-side intelligence would consume.
• Yet another goal of the invention is, in a target/host development environment, to connect all controlled devices as well as the host system to the target machine, particularly when each of N controlled devices requires a respective one of only N available communications interfaces.
• Another object of the invention is, in a target/host development environment, to connect to the host a target machine with no conventional communications interfaces available.
• the present invention is apparatus and methods coupling a first, target processor to a second, host processor.
• the target processor runs a debugging agent while the host processor runs a debugging server application which interacts with its counterpart, the debugging agent.
• the two processors are coupled by a communications link.
• the host processor to retrieve data from the memory of the target processor to the memory of the host, the host processor generates a program in an interpreted language to read the data from the memory of the target processor and communicates that program to the target processor.
• the target processor interprets the program, reading the data and communicating it over the communications link to the host processor.
• the program and/or the data communicated can be compressed for transmission and decompressed on reception.
• the application to be developed and the debugging agent share libraries and provide debugging services from the shared libraries.
• Application and debugging code are partially or fully linked together. User demands are satisfied by executing code in the core common to the application and the debugging agent.
• a copy of the core is placed on the target machine while a copy of the symbol table is placed on the host.
• the debugging agent is then scalable beyond the services in the core by default. The amount of redundancy between the debugging agent and the application is at the discretion of the application developer. The developer controls the impact of the debugging agent on target memory,
• the program text of the debugging agent is supplemented to provide debugging services as the user demands them.
• Scalable debugging agents fundamentally extend the range of scalability beyond that of traditional target/monitor approaches .
• the debugging target and server cooperate to read memory of the target computer into the memory of the host computer coupled to a user input device.
• a user e.g., a user program displaying a thread of execution by continually displaying the relevant stack
• the host computer determines the time differential between the sequential commands and reads the memory in response to the second command only if the time differential is greater than a predetermined value.
• the host computer is again coupled to a user input device.
• the host computer When a user directs a modification of the memory of the target computer, the host computer generates a script for moving data extant in the memory of the target computer and/or copying over data to the memory of the target computer so as to recreate the modification specified by the user.
• the size of the modification is small compared to the size of the total data, communicating the changes rather than the total modified data conserves the limited bandwidth of the communication means coupling the two computers together.
• the target processor is adapted for coupling to and controlling an external device.
• the target processor has a number of communications channels needed to operate in its final configuration, including one which controls the external device.
• the host processor uses this one communications channel for coupling to the target device and uses one of its communications channels to couple the target processor to the external device.
• the invention couples the host computer and the target processor at the debugging target/server level by means of an in-circuit emulator.
• an in-circuit emulator is a ROM emulator.
• Figure 2 illustrates a host/target system with a host-resident cache
• Figure 3 is an abstract diagram of a host/target system and their respective memories;
• Figure 4 illustrates the levels of software supporting an embodiment of a virtual I/O channel;
• Figure 5 illustrates a target and host connected by remote communications
• Figure 6 illustrates the architecture of the target debugging server.
• FIG. 1 illustrates a 8 cross-platform environment 100 incorporating the invention.
• the debugging software is divided in two.
• the first portion of the debugging software, the debugging agent 110 resides on a target computer 120 along with the software 130 undergoing development or debugging.
• the second portion of the debugging software, the debugging server 140 resides on a host computer 150 which provides an interface (here TornadoTM Launcher 160) to the developing or debugging user.
• the target and host computers are connected by means of a communications link 170 which can be serial, parallel, LAN, WAN, or any other form of I/O or hardware-assisted emulator or ro ulator.
• the preferred operating system for the target is the VxWorksTM operating system 130b, available from the assignee of this patent application. Communications between the host and target are by means of the ONC RPC protocol, which can be implemented on virtually any transport layer.
• the host and target respectively support the following services (described from the host's vantage):
• Gophers In order to reduce traffic on the communications link between the target and host, a system uses a first embodiment of the invention: Gophers. Gophers are interpreted programs for efficiently retrieving data from the memory of the target to the memory of the host. Gophers are particularly useful when the data to be retrieved has a complex structure.
• the Gopher language has only one state indicator, a programmable variable referred to as the "pointer.” Also, the Gopher language has only one I/O device, an abstract "tape.” All Gopher actions are interpreted relative to the value of the pointer, and all output is via the tape.
• the Gopher language also includes the following syntactic elements:
• a Gopher can be used to retrieve, for example, the linked list ifnet containing most of the information for network interfaces in the preferred target operating system.
• the structure ifnet is declared as follows: struct ifnet ⁇ char*if_name; /* name , e.g. en' or lo' ⁇ I shortif_unit; /* sub-unit for lower level driver */ shortif_mtu; /* maximum transmission unit */ shortif_flags ; /* up/down, broadcast, etc.
• ifnet is the integer address of the ifnet pointer, which can be obtained from the symbol table by means well-known in the art or by querying the debugging server 140 regarding symbol table 180.
• ⁇ ifnet> sets the value of the Gopher pointer.
• the left brace creates a local copy of the pointer and starts a Gopher loop.
• the Gopher interpreter will execute the subprogram "! + 84 *" until the local copy of the pointer is not NULL (zero) when the right curly brace is reached.
• the syntactic element ! writes the value of the (local) pointer to the output tape, and "+84" then increments the (local) pointer.
• the "*" expression causes the (local) pointer to be replaced by the quantity to which the (local) pointer currently points. A link is thus followed.
• the " ⁇ " delimits the end of the loop, which is terminated when the address to which the (local) pointer currently points is NULL.
• the Gopher evaluator saves unchanged the pointer in effect outside the delimiters and creates and uses another pointer for use during the execution of the delimited expression.
• the evaluator restores the outside pointer when the closing delimiter is executed. While no code follows the closing delimiter in this example, there may, of course, be occasions when such code will exist.
• Gophers have no symbolic capacity and do not understand the layout of structures.
• the "+84" expression was determined from inspecting the size of the elements constituting the ifnet data structure. This is a cost of the language independence of Gophers. Advantages include minimal syntactic elements and compactness.
• the fields of interest in the ifnet data structure are deemed to be the name of the interface, the sub-unit for the lower-level driver, the maximum transmission unit, the flags, the routing metric and the five packet-statistics, respectively, the if name, if_unit, if_mtu, if_flags, if_metric and if_ipackets through if_collisions members.
• the left angle bracket introduces a subcontext which saves the value of the outer pointer.
• the pointer After execution of the ">,” the pointer still points to the top of the data structure, despite the dereferencing and advancement of the local pointer caused by the pointer-replacement and string-write actions.
• the prior art can read large blocks of data of, say, sizeof (struct ifnet) bytes or more. Eighty-four bytes are transferred when only 30 bytes are desired, and some extraneous number of bytes from the large blocks will be transferred as well. Also, the number of RPCs increases as large blocks are read as necessary to retrieve the NULL-terminated name of the interface, and the number of extraneous bytes transferred also increases.
• the prior art can execute a series of RPCs, one for each non-contiguous block of ifnet data structure members desired.
• the number of RPCs remains at the lowest number possible: one. The significance of this cannot be overstated.
• different levels of the communications standard supporting the remote procedure calls e.g., the International Standards Organization ("ISO") Open System Interconnection Reference Model (“OSI”)
• ISO International Standards Organization
• OSI Open System Interconnection Reference Model
• An ability to keep the number of RPCs to the absolute minimum is necessary to minimize bandwidth consumption.
• the prior art can minimize the number of RPCs (and thus the bandwidth consumed in sending data requests) , or it can minimize the amount of data requested (and thus the bandwidth consumed in sending data back) , but the prior art does not minimize both the number of RPCs and the amount of data transferred in response to those RPCs. With its' ability to not merely reduce but truly minimize the consumption of bandwidth, Gophers represent a clear and major improvement over the known art.
• the debugging agent includes an interpreter for the Gopher language. Execution time of the interpreted Gopher is greater than that of a compiled and linked Gopher would be but still represents only a very small fraction of the overall transfer time.
• the Gopher interpreter itself is very small. In fact, the Gopher interpreter available from the assignee of this patent application is smaller than the amount of the memory that would have been required by target routines to gather the data of only the basic system objects.
• a compression-decompression scheme can reduce still further the bandwidth which the transfer of a Gopher program or of the data in response to the Gopher program consumes. If, for example, the linked list in interest was a list of buffers known to be mostly zeroes, a compression-decompression scheme initiated either by the server or the agent and communicated to the other would still further reduce the load on the communications link.
• the Gopher language is compact to reduce communication overhead and is accessible at higher level interfaces within the development environment.
• some or all Gophers are pre- generated based on the information available from the symbol table regarding the data items of interest.
• the server need only recall and transmit the pre-generated Gopher produced in anticipation of that direction.
• this invention provides a scalable debugging agent.
• the debugging server 140 has the capability of incrementally loading object modules into the target system 120. To achieve this end, the debugging server 140 uses the symbol tables contained in every object module to build a system-wide symbol table of functions and variable names loaded in the target system 120. The debugging server 140 adds names from system and application modules 130 alike to the system symbol table. Indeed, the debugging server adds names from the debugging agent 110 itself to the system symbol table.
• Fig. 6 illustrates the architecture of the target debugging server 140.
• the debugging server 140 maintains a copy 610 of the debugging agent 110 on the host (or, at least, a copy of the symbol table of the agent) .
• This copy 610 allows the debugging server 140 to read and analyze the agent 110 's core file to determine what symbols are currently available (resolved) in the agent core. Without a single upload, the debugging server 140 is "bootstrapped" with the core information.
• the debugging server 140 can immediately execute user commands entered through a shell 160 and can perform other functions — constrained only by what services have been linked into the core.
• the host software 160 will typically include a shell 160d or 160e (with underlying hardware, not shown) or other mechanism for communicating with the user.
• the host accepts commands on this user input device from the user.
• a device for user input is most typically a keyboard or mouse. However, a disk, tape or other medium file containing commands previously stored by the user can also be a device for user input.
• Some of these commands the software 160 can satisfy directly; others may require supplemental information or service from the debugging server 140. Still other commands may require information or services which only the agent 110 can provide. For these commands requiring information or services from the agent 110, the debugging server 140 breaks the user command (as relayed by the software 160) into the necessary transactions with the debugging agent 110.
• the debugging server 140 Before the debugging server 140 requests a service of the debugging agent 110, the debugging server 140 checks the host-resident copy 610 of the debugging agent core to determine whether the symbol (s) necessary to provide the service are resolved in the debugging agent 110.
• the debugging server 140 can simply request (e.g., via RPC) that the debugging agent 110 provide the service. Where the symbols providing the requested service are not resolved in the agent 110, the debugging server 140 reads a memory device (not shown) to retrieve the object module containing the text, data, bss or literal sections (depending on the unresolved symbols present and the format of the object module) to which the unresolved symbols refer.
• the host 140 then relinks the debugging agent image on the host 150 to include the new sections, resolving the symbols of interest, and produces a list of differences between the old agent image and the new agent image. Using the differences list, the debugging server 140 then directs the debugging agent 110 through a series of target memory modifications (memory moves, writes, etc.) to reproduce in the target memory the re-linked debugging agent core on the host.
• target memory modifications memory moves, writes, etc.
• the debugging server 140 after reading the memory device to retrieve the sections to which the unresolved symbols refer, directs the debugging agent 110 to accept the sections and relink itself.
• This second embodiment is less preferable in that it requires a larger debugging agent 110 with sufficient intelligence to relink itself.
• the result of both of the foregoing embodiments is a debugging agent 110 with the symbols supporting the requested service resolved.
• the debugging server 140 then directs the debugging agent 110 to perform the desired service, thereby providing the information or service which the host software 160 requires and performing, directly or indirectly, the user's command.
• the debugging server can direct the agent to discard the newly loaded code after use.
• a debugging agent that is scalable allows for an agent equipped to handle one environment, say, a production environment, to be extended when necessary to support another environment, say, a development environment or an in-the-field debugging environment.
• a scalable debugging agent is equipped initially with an optimal subset of the set of all services which it could offer on a target of substantially unlimited resources, and the subset is extendable on demand to offer any of the full set of services.
• scaling of the agent is automatic, occurring in a manner transparent to the user.
• the primary services which a scalable debugging agent 110 offers are target memory write and target service calls. These primary initial services are sufficient to support the corresponding server 140 on the host.
• a program 160 with a user interface for debugging the target software resides on the host.
• this program 160 is the remote source-level CrossWindTM debugger 160d available from the assignee of this patent application.
• the CrossWindTM debugger 160d extends the GNU Source-Level Debugger (GDB) with a graphical user interface and with a comprehensive Tel scripting interface which allows developers to create sophisticated debugger macros and CrossWindTM extensions.
• GDB GNU Source-Level Debugger
• Tel scripting interface which allows developers to create sophisticated debugger macros and CrossWindTM extensions.
• the CrossWindTM debugger 160d permits a user to spawn and debug tasks on the target. The user can also debug already-running tasks spawned with a runtime shell.
• Debugging includes setting system and task-level breakpoints.
• the memory device to which the host debugger 160d refers for the original debugging agent core file or for the additional sections can be a conventional host-based RAM, ROM, disk, user input device or other host-based memory device.
• the host debugger program 160d can query the agent 110 itself for this information.
• the agent 110 is typically loaded from ROM.
• the agent 110 contains the origins of itself and its scaling object modules. Querying the agent 110 allows use of agents 110 other than those provided by the assignee of the patent application because no assumptions are made about the construction of an agent 110. The host explicitly asks the agent 110 for information as necessary.
• the host may request the agent 110 to provide a checksum of its text region. The host then compares this checksum against a checksum of the text region of the core file specified by the agent 110.
• One reason that the two checksums might differ is that the core file on the host may have been updated independently of and after the writing of the agent to the target ROM.
• the types of services which can be thus incrementally loaded are limited only by the services which must initially reside in the target in order to enable the loader and user interface in the server.
• agent services are good candidates for dynamically scaling into the agent 110: Serial line testing, breakpoint support, context (task) control, event support, host exception notification, external context function calls, gophers, memory services, (other than write and move) register access and virtual I/O support.
• the size of the debugging agent 110 in the target memory is guaranteed to always be at a minimum.
• the debugging server 140 can download the supporting code — transparently to the user — to the agent 110. No (or minimal) services will exist in the agent 110 which the user did not actively need and thus no (or minimal) excess code will exist in the target memory.
• the debugging agent 110 is essentially customized for the particular debugging session.
• the invention includes a method for sharing memory between the debugging agent and the operating system software or other application of the target.
• the debugging agent is allowed to grow, consuming more and more memory.
• the debugging agent both grows and shrinks, consuming and releasing memory in the process.
• the invention includes another method for reducing the size of the debugging agent 110 in the memory of the target computer 120.
• application code 130 relies upon a library of functions provided with the application development environment.
• these standard libraries obviate the need for the program developer to program and re-program commonly used routines, and they can make the interfaces to operating system services more programmer-friendly.
• this invention provides a simple mechanism to determine if code is to be shared or not.
• the host-based loader 620 merely references the most recently defined symbol for the purpose of symbol resolution. Duplicate entries in the system symbol table are not rejected. In this way, at his discretion, a user may download redundant copies of services provided by the agent in the core image or may link against the resident services.
• Such an approach need not be limited to the entirety of a library. Even the sharing of a single routine within a resident library can be avoided.
• the application can be linked such that function f() comes from the library shared with the agent.
• Function g() can be supplied in the application's source code, and incrementally downloaded to the system before the remaining body of application code is incrementally downloaded.
• the preferential reference of the loader to the more recent definition of the function g() will resolve the reference to the unshared definition of g() . In prior art, such control over the degree of shared runtime code has not been possible.
• the debugging server In responding to user requests, the debugging server classically turns to the debugging agent, asking for data to be uploaded. The debugging server then uses the uploaded data to produce a response to the user. If the user repeatedly requests the same data, a conventional server will repeatedly request the data of the agent and accordingly prepare the responses to the user.
• the copies of portions of the target memory which have been uploaded and now reside in the memory of the host can be likened to a data cache, with the original data residing on the target computer.
• Gophers performing locking reads to upload data structures associated with system objects. This method insures at least the internal consistency of important objects.
• a system incorporating an embodiment of the invention maintains a variable memory register 230 holding a threshold age. Under certain conditions described below, the system avoids consuming bandwidth with data reads.
• Figure 2 illustrates a host/target system 220 with a host-resident cache 210.
• the host software 140 satisfies data requests from the cache 210 if the data in the cache 210 is younger than the threshold age. If the threshold age is some predetermined value, such as zero, the server 140 always satisfies data requests by reference to the agent 110. Preferably, the user chooses the threshold age for the particular situation. Experiential data suggests that a threshold age of one second suffices for day-to-day situations.
• the server maintains individual age thresholds for respective blocks of data in the host cache. Accordingly, data known or deemed to be volatile can be refreshed at a greater rate than data known or deemed to be more static. In both of these embodiments, the flexibility is in the hands of the user. Another issue associated with caching is writing back: modifying the original when the copy has been modified.
• the debugging server cache 210 disclosed herein is "write-through," the data on the target 120 is updated essentially immediately after the copy on the host 150 is modified. The justification here is that the user always intends to modify the data actually on the target. Indeed, the user may not even be aware that the host software is performing any caching.
• the required writing back can be significantly streamlined.
• the original data in the target memory is unchanging (and, therefore, consistent with the host copy)
• only the writing back of the changed portions of the data is necessary, rather than writing back the entirety of the cached data.
• cache blocks are, say, a kilobyte in size and the change affects only tens or small hundreds of sequential bytes
• an advantage lies in instructing the debugging agent 110 to modify the affected tens or hundreds of bytes rather than instructing the agent 110 to re-write the entire kilobyte.
• Another example is the reloading of a software application or module.
• the invention views the application as a stream of data and the typical recompilation as the insertion and/or deletion of a small portion of the stream.
• the development tools may require resources from the target in addition to those required by the application software on the target.
• These additional resources can be, for instance, sophisticated services which require exclusive access to an allocated portion of target memory.
• sophisticated services which require exclusive access to an allocated portion of target memory.
• dynamic memory management is a technique for managing dynamic memory management.
• Figure 3 is an abstract diagram of a host/target system 300 and the respective memories 310 and 320.
• Systems embodying the invention take into account the fact that the memory 310 of the host system 150 is usually much larger than the memory 320 of the target system 120 and, therefore, the host system 150 can provide storage for many house-keeping data structures used in the management of the target-resident memory 320.
• the debugging agent 110 need only provide services such as move, copy and fill.
• the two data structures typically supporting a memory manager are a free memory list 330 and the allocated list (not shown) .
• the debugging server 140 will allocate host-based memory for these data structures and thus realize zero-overhead performance when allocating target memory.
• the free list 330 is a linked list of free blocks with each link in the list containing the address of the corresponding contiguous free block of memory on the target and the size of this block.
• the list 330 is not ordered, and allocation is achieved with a traditional "first-fit" search of the list.
• the third data structure according to this embodiment is an AVL-tree or binary tree with nodes containing target memory block information sorted within the tree from lower target address to higher target address.
• This data structure is traversed whenever target memory is deallocated, in order to find the host-resident node that corresponds to the target block to be deallocated.
• the use of a b-tree limits the worst-case search to log N, where N is the number of allocated blocks in the tree.
• the target debugging agent manages such data structures.
• target systems incur less overhead in target memory allocation, thus saving resources for application use.
• Another virtue of this invention lies in that host-to-target protocol requests related to memory allocation are greatly reduced limiting the intrusion of host tool memory allocation on the real-time execution of a target system application.
• the target 110 is a device-controlling processor. It has exactly two communications interfaces, one to receive input from a sensor and the second to control a device based on that input. The operations of the device affect the characteristic read by the sensor.
• the memory of the target is limited so that a target/host development environment is preferable or required. The question becomes how to connect the host when both communications ports are necessary for operation of the target.
• a system incorporating the invention maintains virtual I/O (VIO) channels.
• VIO channel can be implemented as a pseudo-tty, a stream as in UNIX®, an underlying device, etc.
• the host 150 redirects communications intended for the controlled device to a communications channel of the host machine, to which communications channel the controlled device is connected.
• the target machine is thus in communication with the sensor, the controlled device and the host computer even though the target machine has only two communications interfaces.
• the operating system 130b supports a virtual I/O device driver 190 to provide target applications 130a with I/O system access to the virtual I/O facility according to the standard system call protocols of the target operating system 130b.
• a first open of a VIO channel is as follows:
• the host 150 associates a VIO channel with any one of a wide variety of devices, including displays, files, raw devices, streams, etc.
• a host application reserves a virtual I/O channel using a system call. As a VIO channel number is used by both the server and agent to determine the source or destination of particular data, the host and target applications must agree as to the channel number.
• the host application typically then redirects the reserved VIO channel to an actual device on the host, using a system call to control the VIO channel. Following is a code sample redirecting VIO channel 4 to a file:
• FIG. 4 illustrates some of the levels of software supporting an embodiment of a virtual I/O channel (from the target to the host) .
• the host 400 includes a virtual console 410 in communication with the target server software 460.
• the target server 460 is in communication with the corresponding debugging agent software 420 residing on the target 440.
• the virtual I/O device driver 430 which is preferably a part of the operating system residing on the target 440.
• Application software 450 makes the standard operating system calls (e.g., write() on a UNIX®-like operating system) to the virtual I/O device driver.
• the virtual I/O device driver 430 instructs the debugging agent to transfer a buffer containing "Hello world ⁇ n" to the debugging server, which then directs the display of the string in the Xterm window 450 on the host 400.
• the ROM emulation provides a full-featured debugging environment to those targets in which no such environment could have existed in prior art.
• the intermediated communications device now provides the communications and off-loads from the target environment a significant portion of the debugging agent dedicated to communications.
• the RAM of the target is often a critical resource. Any technique that reduces the footprint (i.e., storage requirements) on the target of the debugging environment is highly desirable, leaving more target RAM available for application needs.
• a NetROM provides the communications, it reduces the role of the debugging agent and in turn effects considerable savings in target RAM.
• the local agent program code to manage communications with the host would otherwise occupy the now conserved RAM.
• FIG. 5 illustrates a target 520 and a host 530 connected by means of remote communications technology 510.
• a WAN e.g., the global telephone system with modem interfaces or a satellite communications system
• the host 530 and/or target 520 can be anywhere on earth or near space where a port 540 onto the WAN (e.g., a telephone or satellite link) is available.
• the host 530 and/or target 520 can be anywhere that technology reaches.
• the communications technology 510 can be a switching network, allowing any host 530 with the address (e.g., telephone number) of the target modem to connect with the target 520.
• a host-based target server can broker requests for virtually any site.
• the Internet with its suite of applications tracking who's who and where they are, is an excellent example of the remote communications technology 510. Its suite of remote services makes possible bringing up a shell, for example, on any target 520 with a known address. Further, a user can register a target server 530 globally, and an authenticated user can bring up any tool on the associated target 520 for the purpose of remote development, demonstration, technical support, etc.
• This paradigm of distributed World-Wide access to real-time execution platforms shifts the standard usage patterns of cross-development environments from one of single-user work environments to one of distributed development.
• the invention provides on-line access to all registered target systems 520 via their target servers 530 by means of a centralized control panel 160a (Fig. 1) summarizing all available targets and all available tools.
• the Assignee of this invention has succeeded in reducing the size of its debugging agents by an order of magnitude over the prior art.
• Typical agents according to the invention herein are approximately 20 kilobytes (Kb) .
• prior art agents are around 330 to 340 Kb. Consequently, the debugging agents disclosed herein are capable of running in a much broader range of target computers, particularly in those with memory less than 300 Kb.
• the instant invention may be practiced with a single computer system running both the server and the agent.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Hardware Design (AREA)
• Quality & Reliability (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Debugging And Monitoring (AREA)
• Multi Processors (AREA)
• Test And Diagnosis Of Digital Computers (AREA)

Applications Claiming Priority (3)

Publications (2)

Family

ID=24835344

Family Applications (1)

Country Status (3)

Families Citing this family (18)

Citations (2)

Family Cites Families (5)

• 1997
  • 1997-08-21 WO PCT/US1997/014842 patent/WO1998009208A2/en not_active Application Discontinuation
  • 1997-08-21 EP EP97938541A patent/EP0979449A4/de not_active Withdrawn
  • 1997-08-21 JP JP51176598A patent/JP2002515999A/ja active Pending

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events