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).
|