| Home | Wiki | Use Cases | Work Flows | FAQ | Get Involved | Bugzilla | Build | Blog | Documentation

# More Questions?

Bugzilla Questions?
Build and Test Questions?

If your question isn't answered, post it to the frysk@ mailing list or ask it on IRC.

# Some frysk Questions, With Answers

Is frysk Free?
  Yes.
  frysk is available under a "GPL + Exception" license. You can read the license on the license text page or get more information on the annotated license text page.
What is an Execution Analysis Tool?
  An Execution Analysis Tool emphasizes being able to examine, analyze, monitor, and visualize an application as it continues to execute normally.

  With frysk, other operations to more directly control and manipulate the application (such as starting and stopping threads, or modifying variables) are also available.

How does frysk compare to other execution analysis tools, such as `oprofile` and `systemtap`?

  frysk | oprofile | systemtap
  --- | --- | ---
  Strictly user mode | Require kernel modules Requires elevated privilege | Require kernel modules Requires elevated privilege
  100% reliable information | Uses sampling | 100% reliable information
  Active control: can stop or restart a single thread, a process, or an entire application | N/A | Passive

How does frysk compare to a traditional command-line debugger, such as `adb` or `sdb`?
  Here is a quick comparison table that highlights some of the differences:

  traditional | frysk
  --- | ---
  single thread; single process; single host | multi-thread; multi-process; multi-host
  either the program is running or it is stopped—there is no middle ground | non-stop: threads, processes, and hosts can be monitored individually or as a group; by default all are left running
  explicit attach: the user must explicitly start or attach to a process under the debugger's control; operations are strictly limited to the process currently under the debugger's control | always on: the user specifies the operation, frysk handles the details (attaching if and when needed)
  explicit control: the user must explicitly stop, start, or otherwise control the program | event driven: the user specifies the events of interest (program start, exec call, variable change, ...), frysk handles the details
  command-line based | graphical, visual
  assume unoptimized C | assume optimized, inline, multi-threaded, object-oriented, and event-driven code
  debug information loaded immediately, kept in memory | debug information loaded on demand, left on disk, or on the server
  implemented in C; single-threaded, procedural, blocking and polling | implemented in Java and C++; multi-threaded, object-oriented, event-driven

Will there be a scripting language?
  Yes.
  Because the frysk core is directly programmable, the addition of a scripting language such as Guile, Perl, or Python is more than feasible. In fact, there have already been multiple proposals to directly integrate `jython` into frysk.
  As for which scripting language? That choice is yours.
Will there be a command-line interpreter?
  Yes.
  Because the frysk core is directly programmable, the addition of a command-line interpreter such as the High-Performance Debugger Forum Interface or ADB is more than feasible. In fact, the code base already contains a skeleton of the HPD command-line.
Will there be stand-alone utilities?
  Yes.
  frysk's modular design makes possible the implementation of stand-alone utilities including `ftrace` and `fstack`.
Why is frysk written in Java?
Why not use the systems programming language of choice, C?
  frysk is principally written in native Java. Where performance is a significant factor, or where system interfaces are involved, C++/CNI has been used. This has a number of advantages:
  - Those developers who are focused on the rapid development of domain object models and graphical interfaces have access to a modern, object-oriented garbage-collecting language.
  - It avoids the quagmire that comes with fudging objects using a procedure-based language.
  - It provides a solid overlap between developers and users: software engineers working on large, multi-thread, multi-process, object-oriented, distributed applications.
Why use the Java-Gnome Toolkit?
  Like anything, there is a trade off. Below is a quick comparison table highlighting some of the differences. The requirement is for a modern, lightweight toolkit that provides a native look-and-feel, relying only on Free tools.

  | Swing | SWT | Java-GNOME
  --- | --- | --- | ---

  Pro:

  - Mostly JVM independent
    (but is the Free JVM complete?)

  - Native look and feel, sort of
  - Some local knowledge

  - Modern toolkit
  - Some momentum
  - `glade` GUI builder
  - `dogtail` GUI tester

  Con:

  - Not native look-and-feel
  - Not really cross-platform
  - Is the Free implementation complete enough?
  - Free gui builder?
  - Free testing tool?

  - Not true native look-and-feel
  - Somewhat messy
  - Free gui builder?
  - Free testing tool?

  - Under development (mature?)

Will frysk be integrated into Eclipse?
  Yes.
  The frysk core is designed with direct and tight integration into the Eclipse IDE in mind. However, the more immediate need is to provide users with a light-weight, standalone, graphical tool that wraps around the frysk core.
Does frysk replace the traditional command-line debugger?
  No.
  However, traditional debugger users will appreciate frysk when they take on challenging tasks such as analyzing large, complex applications.

Why doesn't `GCC` enable `-fasynchronous-unwind-tables` by default?
  See [PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86 and [PATCH] Omit frame pointer and fix %ebp by default on x86 (take 3).