2016-01-21 6:35 GMT+08:00 Marc Feeley <feeley@iro.umontreal.ca>:
In gdb you need to do

call log_ctrl_flow_history

to generate the control-flow history in the gambit.log file.

However, you have to configure Gambit with --enable-debug so that the code keeps track of the control flow history.

To get the processor state with gdb, it all depends on how Gambit was built.  With --enable-multiple-threaded-vms and/or --enable-multiple-vms there can be more than one processor state.  But if those options aren’t used (the default), then the only processor state will be at the head of the only virtual machine state structure, which is at the head of the global state structure (accessible with ___gstate0).  I’ve never tried it before, but this is what I got:

% gdb gsi
...
(gdb) run
Gambit v4.8.3

>
Program received signal SIGINT, Interrupt.
0x00007fff950e1176 in select$DARWIN_EXTSN ()
   from /usr/lib/system/libsystem_kernel.dylib
(gdb) print ___gstate0
$1 = 1893996

Interesting. When I do that I get a whole structure, including a prettyprint of the ctrl_flow_history.

(gdb) print ___gstate0
$1 = {vmstate0 = {pstate = {{stack_trip = 0x7ffff7ef4048, stack_limit = 0x7ffff7f19720, fp = 0x7ffff7f63458, stack_start = 0x7ffff7f64038, stack_break = 0x7ffff7f634d8,
        heap_limit = 0x7ffff6af2798, hp = 0x7ffff6ae3110, current_thread = 140737335102761, run_queue = 140737335103425, r = {27665313, 140737335103425, -6, 140737335101345, 26720449},
...

Therefore I can just print the individual fields:

(gdb) print ___gstate0.vmstate0.pstate.ctrl_flow_history_index
$4 = 457
(gdb) print ___gstate0.vmstate0.pstate.ctrl_flow_history

Then, you get the actual ___ps address by:

(gdb)  x ___gstate0.vmstate0.pstate
0x1d41140 <___gstate0>: 0xf7ef4048

the first column is the pointer, so

(gdb) call ___print_ctrl_flow_history(0x1d41140)
(gdb)

or simpler, just:

(gdb)  call ___print_ctrl_flow_history(___gstate0.vmstate0.pstate)
(gdb)


Thanks for clarifying about the ___gstate :)