Dear Marc,
How do I actually run "___print_ctrl_flow_history" from a GDB prompt such as the one below?
I have access to global vars, can I pick up the needed ___ps argument from there, or do I need to make an own facility for knowing what ___ps value to use here?
E.g. "call ___print_ctrl_flow_history(123456 )"
Thanks!
$ gdb ./gsc/gsc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/gambit/gsc/gsc...done. (gdb) run Starting program: /tmp/gambit/gsc/gsc Gambit v4.8.3
1 2 3
1
2 3
Program received signal SIGINT, Interrupt. 0x00007ffff6f81433 in select () from /lib/x86_64-linux-gnu/libc.so.6 (gdb)
Afficher les réponses par date
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 = 18939960
Marc
On Jan 20, 2016, at 4:46 PM, Adam adam.mlmb@gmail.com wrote:
Dear Marc,
How do I actually run "___print_ctrl_flow_history" from a GDB prompt such as the one below?
I have access to global vars, can I pick up the needed ___ps argument from there, or do I need to make an own facility for knowing what ___ps value to use here?
E.g. "call ___print_ctrl_flow_history(123456 )"
Thanks!
$ gdb ./gsc/gsc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/gambit/gsc/gsc...done. (gdb) run Starting program: /tmp/gambit/gsc/gsc Gambit v4.8.3
1 2 3
1
2 3
Program received signal SIGINT, Interrupt. 0x00007ffff6f81433 in select () from /lib/x86_64-linux-gnu/libc.so.6 (gdb)
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 :)