WO1998009208A2 - Outil pour diagnostic de logiciel reparti entre plusieurs processeurs - Google Patents

Outil pour diagnostic de logiciel reparti entre plusieurs processeurs Download PDF

Info

Publication number
WO1998009208A2
WO1998009208A2 PCT/US1997/014842 US9714842W WO9809208A2 WO 1998009208 A2 WO1998009208 A2 WO 1998009208A2 US 9714842 W US9714842 W US 9714842W WO 9809208 A2 WO9809208 A2 WO 9809208A2
Authority
WO
WIPO (PCT)
Prior art keywords
memory
processor
program
debugging
data
Prior art date
Application number
PCT/US1997/014842
Other languages
English (en)
Other versions
WO1998009208A3 (fr
Inventor
John C. Fogelin
Colin Smith
David N. Wilner
John Hartman
Kent D. Long
Debbie Steiman-Cameron
Marc Shepard
Yiwen Zhou
Simon Waddington
Philippe Maisonneuve
Pierre-Alain Darlet
Thierry Preyssler
Jean-Claude Oriot
Original Assignee
Wind River Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wind River Systems, Inc. filed Critical Wind River Systems, Inc.
Priority to EP97938541A priority Critical patent/EP0979449A4/fr
Priority to JP51176598A priority patent/JP2002515999A/ja
Publication of WO1998009208A2 publication Critical patent/WO1998009208A2/fr
Publication of WO1998009208A3 publication Critical patent/WO1998009208A3/fr

Links

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)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Multi Processors (AREA)

Abstract

L'invention concerne un système composé d'ordinateurs cibles/hôtes, dans lequel le trafic sur la liaison lors de la connexion et la taille de l'agent dans l'ordinateur cible sont réduits au moyen de Gophers, de services de mise au point à la demande, de bibliothèques d'exécution en commun, de mémoires-caches d'écart de flux quantifié, de gestion de mémoire-cible à base hôte, d'entrées/sorties virtuelles et d'émulation en circuit.
PCT/US1997/014842 1996-08-28 1997-08-21 Outil pour diagnostic de logiciel reparti entre plusieurs processeurs WO1998009208A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP97938541A EP0979449A4 (fr) 1996-08-28 1997-08-21 Outil pour diagnostic de logiciel reparti entre plusieurs processeurs
JP51176598A JP2002515999A (ja) 1996-08-28 1997-08-21 複数プロセッサーで分割されるソフトウエア診断のためのツール

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US70588196A 1996-08-28 1996-08-28
US08/705,881 1996-08-28

Publications (2)

Publication Number Publication Date
WO1998009208A2 true WO1998009208A2 (fr) 1998-03-05
WO1998009208A3 WO1998009208A3 (fr) 1998-07-30

Family

ID=24835344

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/014842 WO1998009208A2 (fr) 1996-08-28 1997-08-21 Outil pour diagnostic de logiciel reparti entre plusieurs processeurs

Country Status (3)

Country Link
EP (1) EP0979449A4 (fr)
JP (1) JP2002515999A (fr)
WO (1) WO1998009208A2 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002023344A2 (fr) * 2000-09-15 2002-03-21 Wind River Systems, Inc. Systeme et procede de communication d'informations de debogage de logiciel, de diagnostic et de maintenance entre dispositifs
US6918108B2 (en) 2001-07-26 2005-07-12 Kyocera Wireless Corp. System and method for field diagnosis of wireless communications device system software
US6957179B2 (en) 2000-10-18 2005-10-18 Stmicroelectronics Limited On-chip emulator communication
US6961537B2 (en) 2001-08-10 2005-11-01 Kyocera Wireless Corp. System and method for peer-to-peer handset communication
US6973591B2 (en) 2000-10-18 2005-12-06 Stmicroelectronics Limited On-chip emulator communication for debugging
US6973592B2 (en) 2000-10-18 2005-12-06 Stmicroelectronics Limited On-chip emulator communication
US7027806B2 (en) 2001-07-26 2006-04-11 Kyocera Wireless, Corp. System and method for field downloading a wireless communications device software code section
US7031903B2 (en) 2000-10-18 2006-04-18 Stmicroelectronics Limited Interface device
EP1410209B1 (fr) * 2001-07-26 2006-05-24 Kyocera Wireless Corp. Systeme et procede destines au diagnostic sur le terrain d'un logiciel de systeme de dispositif de communications sans fil
US7117494B2 (en) 2001-08-10 2006-10-03 Kyocera Wireless Corp. System and method for bi-directional communication and execution of dynamic instruction sets
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
US7184793B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. System and method for over the air area code update
US7184759B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. Modular software components for wireless communication devices
US7254386B2 (en) 2001-08-10 2007-08-07 Kyocera Wireless Corp. System and method for improved security in handset reprovisioning and reprogramming
US7328007B2 (en) 2001-07-26 2008-02-05 Kyocera Wireless Corp. System and method for organizing wireless communication device system software
US7386846B2 (en) 2001-07-26 2008-06-10 Kyocera Wireless Corp. System and method for the management of wireless communications device system software downloads in the field
US9554268B2 (en) 2001-07-26 2017-01-24 Kyocera Corporation System and method for updating persistent data in a wireless communications device
CN116049035A (zh) * 2022-12-27 2023-05-02 合芯科技有限公司 一种缓存一致性的验证和调试的实现方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5162986A (en) * 1990-10-19 1992-11-10 Allen-Bradley Company, Inc. Remote downloading and uploading of motion control program information to and from a motion control I/O module in a programmable controller
US5274815A (en) * 1991-11-01 1993-12-28 Motorola, Inc. Dynamic instruction modifying controller and operation method
US5491796A (en) * 1992-10-23 1996-02-13 Net Labs, Inc. Apparatus for remotely managing diverse information network resources
US5586317A (en) * 1993-07-30 1996-12-17 Apple Computer, Inc. Method and apparatus for implementing I/O in a frame-based computer system
US5590331A (en) * 1994-12-23 1996-12-31 Sun Microsystems, Inc. Method and apparatus for generating platform-standard object files containing machine-independent code
US5689684A (en) * 1995-06-07 1997-11-18 Motorola, Inc. Method and apparatus for automatically reconfiguring a host debugger based on a target MCU identity

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410681A (en) * 1991-11-20 1995-04-25 Apple Computer, Inc. Interpreter for performing remote testing of computer systems

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5162986A (en) * 1990-10-19 1992-11-10 Allen-Bradley Company, Inc. Remote downloading and uploading of motion control program information to and from a motion control I/O module in a programmable controller
US5274815A (en) * 1991-11-01 1993-12-28 Motorola, Inc. Dynamic instruction modifying controller and operation method
US5491796A (en) * 1992-10-23 1996-02-13 Net Labs, Inc. Apparatus for remotely managing diverse information network resources
US5586317A (en) * 1993-07-30 1996-12-17 Apple Computer, Inc. Method and apparatus for implementing I/O in a frame-based computer system
US5590331A (en) * 1994-12-23 1996-12-31 Sun Microsystems, Inc. Method and apparatus for generating platform-standard object files containing machine-independent code
US5689684A (en) * 1995-06-07 1997-11-18 Motorola, Inc. Method and apparatus for automatically reconfiguring a host debugger based on a target MCU identity

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DIGITAL SYSTEMS REPORT, January 1996, Vol. 18, No. 1, DIPIRRO STEVEN, "The Open VMS Alpha System Code Debugger", pages 7-12. XP002971790 *

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002023344A3 (fr) * 2000-09-15 2002-12-05 Wind River Systems Inc Systeme et procede de communication d'informations de debogage de logiciel, de diagnostic et de maintenance entre dispositifs
WO2002023344A2 (fr) * 2000-09-15 2002-03-21 Wind River Systems, Inc. Systeme et procede de communication d'informations de debogage de logiciel, de diagnostic et de maintenance entre dispositifs
US6973592B2 (en) 2000-10-18 2005-12-06 Stmicroelectronics Limited On-chip emulator communication
US6957179B2 (en) 2000-10-18 2005-10-18 Stmicroelectronics Limited On-chip emulator communication
US7031903B2 (en) 2000-10-18 2006-04-18 Stmicroelectronics Limited Interface device
US6973591B2 (en) 2000-10-18 2005-12-06 Stmicroelectronics Limited On-chip emulator communication for debugging
US9554268B2 (en) 2001-07-26 2017-01-24 Kyocera Corporation System and method for updating persistent data in a wireless communications device
US7027806B2 (en) 2001-07-26 2006-04-11 Kyocera Wireless, Corp. System and method for field downloading a wireless communications device software code section
US7386846B2 (en) 2001-07-26 2008-06-10 Kyocera Wireless Corp. System and method for the management of wireless communications device system software downloads in the field
EP1410209B1 (fr) * 2001-07-26 2006-05-24 Kyocera Wireless Corp. Systeme et procede destines au diagnostic sur le terrain d'un logiciel de systeme de dispositif de communications sans fil
US6918108B2 (en) 2001-07-26 2005-07-12 Kyocera Wireless Corp. System and method for field diagnosis of wireless communications device system software
US7143407B2 (en) 2001-07-26 2006-11-28 Kyocera Wireless Corp. System and method for executing wireless communications device dynamic instruction sets
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
US7184793B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. System and method for over the air area code update
US7184759B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. Modular software components for wireless communication devices
US7577126B2 (en) 2001-07-26 2009-08-18 Kyocera Wireless Corp. System and method for over the air area code update
US7328007B2 (en) 2001-07-26 2008-02-05 Kyocera Wireless Corp. System and method for organizing wireless communication device system software
US7117494B2 (en) 2001-08-10 2006-10-03 Kyocera Wireless Corp. System and method for bi-directional communication and execution of dynamic instruction sets
US7254386B2 (en) 2001-08-10 2007-08-07 Kyocera Wireless Corp. System and method for improved security in handset reprovisioning and reprogramming
US6961537B2 (en) 2001-08-10 2005-11-01 Kyocera Wireless Corp. System and method for peer-to-peer handset communication
CN116049035A (zh) * 2022-12-27 2023-05-02 合芯科技有限公司 一种缓存一致性的验证和调试的实现方法
CN116049035B (zh) * 2022-12-27 2024-02-09 合芯科技有限公司 一种缓存一致性的验证和调试的实现方法

Also Published As

Publication number Publication date
WO1998009208A3 (fr) 1998-07-30
JP2002515999A (ja) 2002-05-28
EP0979449A2 (fr) 2000-02-16
EP0979449A4 (fr) 2005-08-24

Similar Documents

Publication Publication Date Title
EP0979449A2 (fr) Outil pour diagnostic de logiciel reparti entre plusieurs processeurs
US7555744B2 (en) Method and system for debugging a program from within a thread of execution of the program
US6385661B1 (en) System and method for dynamic generation of remote proxies
US8595742B2 (en) Executing a distributed java application on a plurality of compute nodes in accordance with a just-in-time compilation history
US9244662B2 (en) Optimizing just-in-time compiling for a java application executing on a compute node
US9086924B2 (en) Executing a distributed java application on a plurality of compute nodes
US6446137B1 (en) Remote procedure call system and method for RPC mechanism independent client and server interfaces interoperable with any of a plurality of remote procedure call backends
US7885978B2 (en) Systems and methods to facilitate utilization of database modeling
US5892941A (en) Multiple user software debugging system
US20050186625A1 (en) Process and system for sharing program fragments
US20040003377A1 (en) Converting byte code instructions to a new instruction set
US20090125611A1 (en) Sharing loaded java classes among a plurality of nodes
US5404519A (en) System for extending software calls to functions on another processor by means of a communications buffer
Breg et al. Java virtual machine support for object serialization
JPH06282481A (ja) サーバ・メモリの管理
US20060242631A1 (en) Process and system for sharing program fragments
JP2991242B2 (ja) マルチプロセッサコンピュータシステム使用方法
Andersson et al. Kaffemik-A distributed JVM on a single address space architecture
Kessler A client-side stub interpreter
US7774756B1 (en) Method and system for creating a logical view out of remote method invocations
Hsueh et al. EcoExec: An interactive execution framework for ultra compact wireless sensor nodes
Weiher et al. Standard Object Out
US20040010779A1 (en) Multi-module interpreter
den Burger et al. What is the price of simplicity? a cross-platform evaluation of the saga api
Barzilay The Racket Foreign Interface

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): JP

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1997938541

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1997938541

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1997938541

Country of ref document: EP