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 <sc>C</sc> and using <sc>POSIX</sc> 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 (<sc>JVM</sc>) 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 (<sc>JDWP</sc>).