|
When a program is being debugged, you would like to recall what has
already been done in order to replay a portion of an execution.
Obviously, it is useful to have an history of executed commands,
because you don't want to redo a huge number of commands manually, or
because you want to be able to replay execution later.
Bugloo can help you to do this kind of things, with its
concept of debug sessions.
Print the current history
| (history clear) | Bugloo command |
Clear the current history
The command history dump to screen to actual state of the debug
session.It does not add itself into history however...
Each time you do a command with Bugloo, it is added into history. But
this behavior is not desired all the time. For example with the Emacs
frontend of Bugloo, each time you step into the code the debugger is
asked informations about the call stack. You tipically don't want
these requests to pollute the history.
| (history freeze) | Bugloo command |
Disable history recording
| (history freeze all) | Bugloo command |
Disable history recording and prompt display
| (history thaw) | Bugloo command |
Enable history recording again
Note that these commands are not appended to history.
| (history load <filename>) | Bugloo command |
Load history from file <filename>
| (history save <filename>) | Bugloo command |
Save history to file <filename>
| argument | description |
|---|
| <filename>::string | The location of the file containing history |
None of these two commands modify the current history. In particular,
this means that when Bugloo loads an history from file, current
history does not become the one in the file. Rather, commands from the
file are executed in the debugger.
Loading an history from file is the action of executing inside the
debugger every command that the file contains. It is thus possible to
have a notion of debug session, because you can replay
debuggee execution, modulo the non determinism (e.g. the thread
scheduling).
This functionnality can be seen as a mean to manage configuration
files too. That's the manner Bugloo uses it. During startup, a global
site configuration file is loaded. It is this file that configures the
default Name Manglers, the Displayers or the Extended Filters :
1:;*=====================================================================*/
2:;* bugloo/runtime/bugloo-init.cmd */
3:;* ------------------------------------------------------------- */
4:;* Author : Damien Ciabrini */
5:;* Creation : Thu Nov 28 12:20:38 2002 */
6:;* Last change : Thu Nov 28 12:20:47 2002 (dciabrin) */
7:;* Copyright : 2002 Damien Ciabrini, see LICENCE file */
8:;* ------------------------------------------------------------- */
9:;* The Bugloo Debugger Site Init File */
10:;* (add your own init by editing your ~/.bugloo/init.cmd file) */
11:;*=====================================================================*/
12:
13:;; Load default manglers for Java and Scheme languages ...
14:;; (things that will be called to properly demangle methods and ident name)
15:(mangler add java bugloo.features.JavaNameMangler)
16:(mangler add bigloo bugloo.features.BiglooNameMangler)
17:
18:;; Load all known displayers for these languages ...
19:;; (things that will be called to display the value of args and variables)
20:(displayer add java tostring bugloo.features.JavaDisplayer)
21:(displayer add bigloo display bugloo.features.DisplayDisplayer)
22:(displayer add bigloo write bugloo.features.WriteDisplayer)
23:(displayer add bigloo write-circle bugloo.features.WriteCircleDisplayer)
24:(displayer add bigloo display-circle bugloo.features.DisplayCircleDisplayer)
25:
26:;; Set the default displayers ...
27:(displayer set java tostring)
28:(displayer set bigloo write-circle)
29:
30:
31:;; Class filter is part of the JVMDI API. It is done in the debuggee
32:;; VM, and allows traffic diminution when stepping into the code.
33:
34:;; A default (quite reasonable) class filter for scheme debugging ...
35:(filter class add
36: ("java.*"
37: "javax.*"
38: "sun.*"
39: "com.sun.*"
40: "bigloo.*"))
41:
42:
43:;; Extended filter are more powerful, in that they allow full stepping
44:;; control over the methods traced. But they are bugloo addition to JVMDI
45:;; debugging facilities. They can't stop traffic between the debugger and
46:;; the debuggee, and thus are slower than classic class filter.
47:
48:;; A default extended filter to mask some bigloo implementation tricks ...
49:(filter ext add ("\\.funcall[0-4]\\(" . next))
50:(filter ext add ("<clinit>" . next))
51:(filter ext add ("<init>" . next))
52:
53:;; Try to eval user-specific init file
54:(history load "~/.bugloo/init.cmd") |
At the end of the configuration file, Bugloo automatically try to load
some personnal configuration, giving you the ability to customize the
default behavior of the debugger.
|