CodeEyes.com

CodeEyes^TM uses natively produced symbol files to map application variables to memory locations where they are accessed via the OS, outside the application address space. The native symbol files are produced by compilers such as those found in Borland and Microsoft IDEs, and embedded compilers such as GHS Multi and Wind River Tornado IDE. This means no special compilation is required to use with CodeEyes^TM, which cannot be said for other instrumentation tools. Furthermore, variables originating from different applications with different native symbol file formats can coexist on the same graph providing instrumentation synchronization across disparate applications. The current symbol file formats supported, and their associated compilers, are listed below.

An example of synchronized instrumentation across two disparate applications is illustrated. The first application is written in Visual Basic and runs in a .Net framework, and the other is written in C++ and runs in an embedded system. CodeEyes^TM uses the associated symbol for each, PE/COFF and Elf/DWARF 2 respectively, to determine the absolute address to access. CodeEyes^TM then sets up a channel to the variable via agents running on the host. Both variables, A and B, are synchronized in the presentation layer views.

CodeEyes^TM architecture is comprised of four components; three that make up the Model View Controller (MVC) framework of the application in which the user interacts with, and a fourth Agent component which is responsible for accessing memory locations.

The function of the four components is described below:

Model
Provides the interface to the variables via the Agent, and determines the memory location of the variable from the symbol file.

View
Provides the GUI to specify the applications and the associated variables to monitor, and to present the data in various graphical representations including tabular, strip chart, spectral, statistical and buffered views.

Controller
Provides the engines that control the Agent interfaces, and the dispatching of data to the various views and buffer.

Agent
Provides the mapping to the memory location via the OS.

The interface between the Model and Agent components implements a Common API which allows new Agents to be developed, extending the instrumentation capability without affecting the core MVC components. New Agents can be developed for additional OS’s, embedded systems, even for non-memory sources, such as databases and messaging systems. Currently there are agents for the Win32 and GHS Integrity Real-Time Operating System (RTOS). Linux, Unix, VxWorks, Java Virtual Machines, including both Microsoft and Sun, and others are planned