An overview of the frysk Execution Analysis Technology.
Overview
At a high level, frysk's architecture can be viewed as a
collection of clients that interact with frysk's core.
frysk's core providing clients with alternate models of the
system.
frysk then uses the target system's kernel interfaces to
maintain its internal models.
Each of the components that make up frysk are discussed
below.
frysk's Core
A Layered Architecture
An application running on a linux system can modeled at several
different levels, each level providing a different of abstraction.
For instance a distributed application, consisting of multiple
processes and threads, running across multiple physical machines can
be viewed, or modeled, as:
-
A shared-memory multi-processor executing machine instructions on a
local machine.
-
A multi-threaded program written in C and using
POSIX threads.
-
A distributed application, made up of a number of programs distributed
across multiple machines.
Each level of abstraction (or model) being implemented using the
layers below.
This can be depicted visually as:
This structure is characterized as The Layered
Architecture, and key benefits and characteristics of this
architecture include:
Benefits:
-
Segmentation of high-level from low-level issues.
-
The implementation details of a layer are hidden (abstracted) from
other layers.
-
Many upper layers can share the services of a lower layer.
Dynamics:
-
Requests percolate downward between layers.
-
Notifications percolate upward between layers.
-
Layers can improve performance by caching requests.
In addition, a layered architecture, permits the distribution of
components across a network. For instance, in the case of a cluster,
and dependent on the performance requirements, one or more components
may be local or remote:
For further discussion of layered architectures, see Layered
Architecture.
Kernel Interface
At the lowest level, is frysk's interface to underlying operating
system (or kernel). The interface is implemented using {@link
frysk.sys}, kernel level events as they arrive, being managed using
{@link frysk.event} (frysk's event loop).
For instance, when implementing single-step, the kernel will generate
stop events as illustrated by:
For further information, see {@link frysk.sys}, and {@link
frysk.event}.
Process Model
The Linux Process Layer abstracts the Kernel
Layer, multi-processor machine in more exacting details. This
abstraction models individual registers, the program-counter, and
hardware breakpoints and watchpoints. It also implements more complex
operations such as step-out-of-range (implemented using lower-level
primitives).
See {@link frysk.proc}, for more information.
Language Model
The language model provides a source-language view of the running
application. The model includes abstractions for high-level language
concepts such as thread, frame and variable.
High level language support is implemented within this layer.
See {@link frysk.lang}, for more information.
Application Model
For an application distributed across multiple nodes of a cluster,
there is an additional Cluster Layer, providing an overriding model of
the system being debugged.
Command Line Interpreter
Built into frysk is a command line interpreter based on the
specification published by the High Performance Debugger Forum.
Additional interpreters (such as adb), and scripting
languages (such as scheme and Python) may be
added at some stage in the future.
See {@link frysk.cli.hpd} for more information in frysk's existing
interpreter.
Clients
GUI
See {@link frysk.gui} for a more detailed description of frysk's
graphical interface.
Command Line Utilities
Frysk includes a number of command line utilities, at present they
include: {@link frysk.bin.ftrace} to trace the system calls of running
processes, {@link frysk.bin.fstack} to print the current stack of a
running process. These utilities are implemented by directly
interacting with frysk's process model:
In the future, a stand-alone command-line tool, that provides a
wrapper around frysk's built in High Performance Debugger
Interpreter, or more traditional debugger interface (such as
adb) may be added. For the moment, that interface is
only available via the GUI.
Eclipse
There are many ways that Eclipse can exploit frysk. For
instance, by using libgcj_db library, along with
knowledge of the internals of a Java Virtual Machine (JVM)
running within a process, an abstract model of a Java Virtual Machine
can then be constructed. That model being exported to Eclipse using
the Java Debug Wire Protocol (JDWP).
