* Re: [discuss] Support for reverse-execution @ 2005-05-19 1:23 Dan Shearer 2005-05-19 13:01 ` Johan Rydberg 2005-05-20 10:47 ` Eli Zaretskii 0 siblings, 2 replies; 80+ messages in thread From: Dan Shearer @ 2005-05-19 1:23 UTC (permalink / raw) To: gdb Johan Rydberg, a developer at Virtutech, has got some patches against 6.3 (for discussion only) that he'll be sending along to this list. I want to bring up bookmarks for discussion, a topic that isn't yet addressed by his patches. First, what is addressed: Johan has implemented the reverse instructions rstep, rstepi, rnext and rnexti for PowerPC, Sparc and Sparc64 targets. Next to appear will be rcontinue (easy) and rfinish (not so easy), however all of these are obvious reversible analogues to the conventional commands. You should see these when Sweden wakes up next. Bookmarks are not about reversibility, they are about checkpointing. To understand bookmarks you first have to think about what a reversible target is. Any simulator (or real hardware for that matter) capable of reversibility has a mechanism to keep or re-generate all system state and the ability to restart execution from any point in that stored state. Bookmarking is a way of exposing this functionality to the user. Imagine two new gdb commands, get-bookmark and goto-bookmark. get-bookmark asks the simulator for a token which uniquely identifies the current state of the system. goto-bookmark gives a token back to the simulator and asks the simulator to load system state as it was at the time of the bookmark. The token is an arbitary number that makes sense to the particular simulator. Some might count in clock cycles, others in milliseconds or maybe the number of the checkpoint that corresponds to the state at that time. All gdb knows about is the value of the bookmark. This gives a gdb user the capability to explore alternative futures without a complicated interface. A sequence might be get-bookmark, change a value, run for ten seconds. Break, goto-bookmark, try another value and run for ten seconds. Like an infinite rewind-replay facility, very helpful when part of the pain is getting the circumstances just right for the bug to appear. It would be an interesting discussion to see how bookmarks could be incorporated into the gdb framework. -- Dan Shearer dan@shearer.org ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 1:23 [discuss] Support for reverse-execution Dan Shearer @ 2005-05-19 13:01 ` Johan Rydberg 2005-05-19 13:18 ` Daniel Jacobowitz 2005-05-20 10:37 ` Eli Zaretskii 2005-05-20 10:47 ` Eli Zaretskii 1 sibling, 2 replies; 80+ messages in thread From: Johan Rydberg @ 2005-05-19 13:01 UTC (permalink / raw) To: Dan Shearer; +Cc: gdb [-- Attachment #1: Type: text/plain, Size: 2026 bytes --] Dan Shearer wrote: > Johan Rydberg, a developer at Virtutech, has got some patches against > 6.3 (for discussion only) that he'll be sending along to this list. I > want to bring up bookmarks for discussion, a topic that isn't yet > addressed by his patches. > > First, what is addressed: Johan has implemented the reverse instructions > rstep, rstepi, rnext and rnexti for PowerPC, Sparc and Sparc64 targets. > [...] Here's a patch against CVS that implements the following commands: - rstep, rstepi - rnext, rnexti The obvious commands "rcontinue" and "rfinished" are not yet implemented, and therefor not included in this patch. The command names are of course up for discussion. Other things that is missing from the patch: - Error handling. GDB will not complain if the remote stub does not implement reverse execution. - Documentaton of the commands. - Some corner cases are not handled yet. - Mechanism for working with bookmarks. What I have done is add a new variable, step_direction, that can either be STEP_DIR_FORWARD or STEP_DIR_REVERSE. A new target vector has also been added; to_reverse. The remote protocol has been extended with two new functions: "bs" and "bc" To implement "rnext" I had to add a new target-specific function that tries to figure out the address of the call instruction based on the last executed instruction and the instruction to be executed, IF the current instruction can be identified as a return insn. This patch should not been seen as a straight forward contribution, but as a proof-of-concept implementation. A lot of things could probably be done better, and more in the "GDB-way", so any input is will appreciated. Currently the patch only works for PowerPC and SPARC targets, though I plan to add support for a few more targets in the near future. Obviously it is a bit hard to test without access to a reversible target but we are working on changing that in the next month or so (Dan has more information on that.) Thanks, Johan [-- Attachment #2: gdb-reverse-1.patch --] [-- Type: text/x-patch, Size: 19492 bytes --] Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.361 diff -u -r1.361 gdbarch.sh --- gdbarch.sh 14 May 2005 06:07:41 -0000 1.361 +++ gdbarch.sh 19 May 2005 12:57:30 -0000 @@ -591,6 +591,10 @@ v:=:int:frame_red_zone_size # m::CORE_ADDR:convert_from_func_ptr_addr:CORE_ADDR addr, struct target_ops *targ:addr, targ::convert_from_func_ptr_addr_identity::0 + +# When running backwards it's needed to calculate the address of the +# call instruction when the single stepper hits a return insn. +f:=:int:call_insn_from_return_addr:CORE_ADDR pc, CORE_ADDR prev_pc, CORE_ADDR *call_pc:pc, prev_pc, call_pc::0: # On some machines there are bits in addresses which are not really # part of the address, but are used by the kernel, the hardware, etc. # for special purposes. ADDR_BITS_REMOVE takes out any such bits so Index: infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.137 diff -u -r1.137 infcmd.c --- infcmd.c 12 May 2005 20:21:17 -0000 1.137 +++ infcmd.c 19 May 2005 12:57:30 -0000 @@ -100,7 +100,7 @@ static void jump_command (char *, int); -static void step_1 (int, int, char *); +static void step_1 (int, int, char *, enum step_direction_kind); static void step_once (int skip_subroutines, int single_inst, int count); static void step_1_continuation (struct continuation_arg *arg); @@ -579,13 +579,39 @@ proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0); } + +\f +static void +rstep_command (char *count_string, int from_tty) +{ + step_1 (0, 0, count_string, STEP_DIR_REVERSE); +} + +static void +rstepi_command (char *count_string, int from_tty) +{ + step_1 (0, 1, count_string, STEP_DIR_REVERSE); +} + +static void +rnext_command (char *count_string, int from_tty) +{ + step_1 (1, 0, count_string, STEP_DIR_REVERSE); +} + +static void +rnexti_command (char *count_string, int from_tty) +{ + step_1 (1, 1, count_string, STEP_DIR_REVERSE); +} + \f /* Step until outside of current statement. */ static void step_command (char *count_string, int from_tty) { - step_1 (0, 0, count_string); + step_1 (0, 0, count_string, STEP_DIR_FORWARD); } /* Likewise, but skip over subroutine calls as if single instructions. */ @@ -593,7 +619,7 @@ static void next_command (char *count_string, int from_tty) { - step_1 (1, 0, count_string); + step_1 (1, 0, count_string, STEP_DIR_FORWARD); } /* Likewise, but step only one instruction. */ @@ -601,13 +627,13 @@ void stepi_command (char *count_string, int from_tty) { - step_1 (0, 1, count_string); + step_1 (0, 1, count_string, STEP_DIR_FORWARD); } void nexti_command (char *count_string, int from_tty) { - step_1 (1, 1, count_string); + step_1 (1, 1, count_string, STEP_DIR_FORWARD); } static void @@ -617,7 +643,8 @@ } static void -step_1 (int skip_subroutines, int single_inst, char *count_string) +step_1 (int skip_subroutines, int single_inst, char *count_string, + enum step_direction_kind direction) { int count = 1; struct frame_info *frame; @@ -659,6 +686,7 @@ for (; count > 0; count--) { clear_proceed_status (); + step_direction = direction; frame = get_current_frame (); if (!frame) /* Avoid coredump here. Why tho? */ @@ -712,6 +740,8 @@ and handle them one at the time, through step_once(). */ else { + gdb_assert (0); + if (target_can_async_p ()) step_once (skip_subroutines, single_inst, count); } @@ -2082,6 +2112,16 @@ Argument N means do this N times (or till program stops for another reason).")); add_com_alias ("ni", "nexti", class_alias, 0); + add_com ("rstepi", class_run, rstepi_command, + "Reverse one instruction, but proceed through subroutine calls.\n\ +Argument N means do this N times (or till program stops for another reason)."); + add_com_alias ("rsi", "rstepi", class_alias, 0); + + add_com ("rnexti", class_run, rnexti_command, + "Reverse one instruction, skipping subroutine calls.\n\ +Argument N means do this N times (or till program stops for another reason)."); + add_com_alias ("rni", "rnexti", class_run, 1); + add_com ("finish", class_run, finish_command, _("\ Execute until selected stack frame returns.\n\ Upon return, the value returned is printed and put in the value history.")); @@ -2100,6 +2140,16 @@ Argument N means do this N times (or till program stops for another reason).")); add_com_alias ("s", "step", class_run, 1); + add_com ("rstep", class_run, rstep_command, + "Reverse program until it reaches a different source line.\n\ +Argument N means do this N times (or till program stops for another reason)."); + add_com_alias ("rs", "rstep", class_run, 1); + + add_com ("rnext", class_run, rnext_command, + "Step program until it reaches the previous source line.\n\ +Argument N means do this N times (or till program stops for another reason)."); + add_com_alias ("rn", "rnext", class_run, 1); + c = add_com ("until", class_run, until_command, _("\ Execute until the program reaches a source line greater than the current\n\ or a specified location (same args as break command) within the current frame.")); Index: inferior.h =================================================================== RCS file: /cvs/src/src/gdb/inferior.h,v retrieving revision 1.71 diff -u -r1.71 inferior.h --- inferior.h 14 May 2005 06:07:42 -0000 1.71 +++ inferior.h 19 May 2005 12:57:30 -0000 @@ -373,6 +373,17 @@ extern enum step_over_calls_kind step_over_calls; +/* STEP_DIR_FORWARD means normal execution, + STEP_DIR_REVERSE means going back in time. */ + +enum step_direction_kind + { + STEP_DIR_FORWARD, + STEP_DIR_REVERSE + }; + +extern enum step_direction_kind step_direction; + /* If stepping, nonzero means step count is > 1 so don't print frame next time inferior stops if it stops due to stepping. */ Index: infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.201 diff -u -r1.201 infrun.c --- infrun.c 12 May 2005 20:21:17 -0000 1.201 +++ infrun.c 19 May 2005 12:57:32 -0000 @@ -247,6 +247,10 @@ static struct symbol *step_start_function; +/* Direction of which the execution is heading. */ + +enum step_direction_kind step_direction; + /* Nonzero if we are expecting a trace trap and should proceed from it. */ static int trap_expected; @@ -509,7 +513,6 @@ } } - /* Resume the inferior, but allow a QUIT. This is useful if the user wants to interrupt some lengthy single-stepping operation (for child processes, the SIGINT goes to the inferior, and so @@ -620,13 +623,19 @@ if (step && breakpoints_inserted && breakpoint_here_p (read_pc ())) step = 0; } - target_resume (resume_ptid, step, sig); + + if (step_direction == STEP_DIR_FORWARD) + target_resume (resume_ptid, step, sig); + else + { + target_reverse (resume_ptid, step); + } } discard_cleanups (old_cleanups); } -\f +\f /* Clear out all variables saying what to do when inferior is continued. First do this, then set the ones you want, then call `proceed'. */ @@ -638,6 +647,7 @@ step_range_end = 0; step_frame_id = null_frame_id; step_over_calls = STEP_OVER_UNDEBUGGABLE; + step_direction = STEP_DIR_FORWARD; stop_after_trap = 0; stop_soon = NO_STOP_QUIETLY; proceed_to_finish = 0; @@ -2099,6 +2109,21 @@ if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: BPSTATE_WHAT_STEP_RESUME\n"); + /* If stepping over functions calls while reversing we might + have to still continue running even if we hit the + breakpoint. This to enable "prev" to step over recursive + calls. */ + if (step_over_calls == STEP_OVER_ALL + && step_direction == STEP_DIR_REVERSE + && (frame_id_inner (frame_unwind_id (get_current_frame ()), + step_frame_id) + || frame_id_eq (frame_unwind_id (get_current_frame ()), + step_frame_id))) + { + keep_going (ecs); + return; + } + if (step_resume_breakpoint == NULL) { step_resume_breakpoint = @@ -2117,6 +2142,17 @@ keep_going (ecs); return; } + /* If running backwards break out of this step-resume + breakpoint was set on the first insn in the line. */ + + if (step_direction == STEP_DIR_REVERSE + && stop_pc == step_range_start) + { + stop_step = 1; + print_stop_reason (END_STEPPING_RANGE, 0); + stop_stepping (ecs); + return; + } break; case BPSTAT_WHAT_THROUGH_SIGTRAMP: @@ -2268,7 +2304,7 @@ return; } - if (step_resume_breakpoint) + if (step_resume_breakpoint && step_direction != STEP_DIR_REVERSE) { if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: step-resume breakpoint\n"); @@ -2288,13 +2324,21 @@ keep_going (ecs); return; } - + /* If stepping through a line, keep going if still within it. - + Note that step_range_end is the address of the first instruction - beyond the step range, and NOT the address of the last instruction - within it! */ - if (stop_pc >= step_range_start && stop_pc < step_range_end) + beyond the step range, and NOT the address of the last + instruction within it! Also, if running backwards, stop if we + hit the first instruction in the line. */ + if (step_direction == STEP_DIR_REVERSE && stop_pc == step_range_start) + { + stop_step = 1; + print_stop_reason (END_STEPPING_RANGE, 0); + stop_stepping (ecs); + return; + } + else if (stop_pc >= step_range_start && stop_pc < step_range_end) { if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: stepping inside range [0x%s-0x%s]\n", @@ -2511,16 +2555,43 @@ } else { - /* Set a breakpoint at callee's return address (the address - at which the caller will resume). */ - insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ())); - keep_going (ecs); - return; + if (step_direction == STEP_DIR_FORWARD) + { + /* Set a breakpoint at callee's return address (the + address at which the caller will resume). */ + insert_step_resume_breakpoint_at_frame + (get_prev_frame (get_current_frame ())); + keep_going (ecs); + return; + } + else + { + /* FIXME: gdb-reverse */ + gdb_assert (0); + } } } if (step_range_end == 1) { + CORE_ADDR call_pc; + + /* For previ we must also check so we did not just end up inside + a subroutine. */ + if (step_direction == STEP_DIR_REVERSE + && step_over_calls == STEP_OVER_ALL + && CALL_INSN_FROM_RETURN_ADDR (stop_pc, prev_pc, &call_pc)) + { + struct symtab_and_line sr_sal; + + init_sal (&sr_sal); + sr_sal.pc = call_pc; + + insert_step_resume_breakpoint_at_sal (sr_sal, null_frame_id); + keep_going (ecs); + return; + } + /* It is stepi or nexti. We always want to stop stepping after one instruction. */ if (debug_infrun) @@ -2563,6 +2634,32 @@ return; } + if (step_direction == STEP_DIR_REVERSE + && step_over_calls == STEP_OVER_ALL) + { + /* Going backwards we can make the assumption that if stop_pc is + not within the stepping range, prev_pc was the target of a + branch (insn that stop_pc points to). If stop_pc is a return + instruction, and subroutine calls should be stepped over, do + it here. It is also known that prev_pc was the last executed + insn, i.e., the target of the branch. */ + /* It has already been proven that stop_pc is not within the + stepping range. */ + CORE_ADDR call_pc; + + if (CALL_INSN_FROM_RETURN_ADDR (stop_pc, prev_pc, &call_pc)) + { + struct symtab_and_line sr_sal; + + init_sal (&sr_sal); + sr_sal.pc = call_pc; + + insert_step_resume_breakpoint_at_sal (sr_sal, step_frame_id); + keep_going (ecs); + return; + } + } + /* We aren't done stepping. Optimize by setting the stepping range to the line. @@ -2570,7 +2667,8 @@ new line in mid-statement, we continue stepping. This makes things like for(;;) statements work better.) */ - if (ecs->stop_func_end && ecs->sal.end >= ecs->stop_func_end) + if (ecs->stop_func_end && ecs->sal.end >= ecs->stop_func_end + && step_direction == STEP_DIR_FORWARD) { /* If this is the last line of the function, don't keep stepping (it would probably step us out of the function). @@ -2621,7 +2719,7 @@ } /* Are we in the middle of stepping? */ - + static int currently_stepping (struct execution_control_state *ecs) { Index: remote.c =================================================================== RCS file: /cvs/src/src/gdb/remote.c,v retrieving revision 1.190 diff -u -r1.190 remote.c --- remote.c 16 May 2005 16:36:24 -0000 1.190 +++ remote.c 19 May 2005 12:57:32 -0000 @@ -2617,6 +2617,26 @@ if (target_is_async_p ()) target_executing = 1; } + +/* Run in reverse. */ +static int +remote_reverse (ptid_t ptid, int step) +{ + struct remote_state *rs = get_remote_state (); + char *buf = alloca (rs->remote_packet_size); + int pid = PIDGET (ptid); + + /* All other supported resume packets do use Hc, so call set_thread. */ + if (pid == -1) + set_thread (0, 0); /* run any thread */ + else + set_thread (pid, 0); /* run this thread */ + + strcpy (buf, step ? "bs" : "bc"); + putpkt (buf); + + return 0; +} \f /* Set up the signal handler for SIGINT, while the target is @@ -5413,6 +5433,7 @@ remote_ops.to_has_registers = 1; remote_ops.to_has_execution = 1; remote_ops.to_has_thread_control = tc_schedlock; /* can lock scheduler */ + remote_ops.to_reverse = remote_reverse; remote_ops.to_magic = OPS_MAGIC; } Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.240 diff -u -r1.240 rs6000-tdep.c --- rs6000-tdep.c 1 May 2005 19:58:55 -0000 1.240 +++ rs6000-tdep.c 19 May 2005 12:57:33 -0000 @@ -2824,6 +2824,26 @@ else return print_insn_little_powerpc (memaddr, info); } + +\f +static int +rs6000_call_insn_from_return_addr (CORE_ADDR pc, CORE_ADDR prev_pc, + CORE_ADDR *call_pc) +{ + char buf[4]; + + if (target_read_memory (pc, buf, 4)) + return 0; + + if (extract_unsigned_integer (buf, 4) == 0x4e800020) + { + *call_pc = prev_pc - 4; + return 1; + } + + return 0; +} + \f static CORE_ADDR rs6000_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame) @@ -3302,6 +3322,7 @@ set_gdbarch_convert_register_p (gdbarch, rs6000_convert_register_p); set_gdbarch_register_to_value (gdbarch, rs6000_register_to_value); set_gdbarch_value_to_register (gdbarch, rs6000_value_to_register); + set_gdbarch_call_insn_from_return_addr (gdbarch, rs6000_call_insn_from_return_addr); set_gdbarch_stab_reg_to_regnum (gdbarch, rs6000_stab_reg_to_regnum); set_gdbarch_dwarf2_reg_to_regnum (gdbarch, rs6000_dwarf2_reg_to_regnum); Index: sparc-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/sparc-tdep.c,v retrieving revision 1.163 diff -u -r1.163 sparc-tdep.c --- sparc-tdep.c 14 May 2005 13:45:22 -0000 1.163 +++ sparc-tdep.c 19 May 2005 12:57:33 -0000 @@ -868,6 +868,57 @@ } \f +static int +return_insn_p (unsigned int v, int *regno) +{ + if (v == 0x81c7e008) /* jmpl %i7+8,%g0 */ + { + *regno = SPARC_I7_REGNUM; + return 1; + } + else if (v == 0x81c3e008) /* jmpl %o7+8,%g0 */ + { + *regno = SPARC_O7_REGNUM; + return 1; + } + else + { + /* FIXME: more cases? */ + return 0; + } +} + +static int +sparc_call_insn_from_return_addr (CORE_ADDR pc, CORE_ADDR prev_pc, + CORE_ADDR *call_pc) +{ + struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); + int regno; + + /* Calculating the address of the call instruction is quite tricky. + First we must check so that pc - 4 is a return insn, and that it + has already been executed (i.e., that the insn at PC is really in + PC-4's delay slot). This is done by checking the value of the + NPC register. */ + + if (return_insn_p (sparc_fetch_instruction (pc - 4), ®no)) + { + static CORE_ADDR npc, reg; + + npc = sparc_address_from_register (tdep->npc_regnum); + reg = sparc_address_from_register (regno); + + /* Set *call_pc so it points to the delay slot of the call + instruction. This is needed for the "previ" case. */ + *call_pc = prev_pc - 4; + return ((reg == prev_pc - 8) && npc == prev_pc); + } + + return 0; +} + +\f + /* Extract from an array REGBUF containing the (raw) register state, a function return value of TYPE, and copy that into VALBUF. */ @@ -1211,6 +1262,8 @@ set_gdbarch_pc_regnum (gdbarch, SPARC32_PC_REGNUM); /* %pc */ set_gdbarch_fp0_regnum (gdbarch, SPARC_F0_REGNUM); /* %f0 */ + set_gdbarch_call_insn_from_return_addr (gdbarch, sparc_call_insn_from_return_addr); + /* Call dummy code. */ set_gdbarch_call_dummy_location (gdbarch, ON_STACK); set_gdbarch_push_dummy_code (gdbarch, sparc32_push_dummy_code); Index: target.c =================================================================== RCS file: /cvs/src/src/gdb/target.c,v retrieving revision 1.108 diff -u -r1.108 target.c --- target.c 16 May 2005 16:36:24 -0000 1.108 +++ target.c 19 May 2005 12:57:33 -0000 @@ -457,6 +457,7 @@ INHERIT (to_make_corefile_notes, t); INHERIT (to_get_thread_local_address, t); INHERIT (to_magic, t); + INHERIT (to_reverse, t); } #undef INHERIT Index: target.h =================================================================== RCS file: /cvs/src/src/gdb/target.h,v retrieving revision 1.73 diff -u -r1.73 target.h --- target.h 16 May 2005 04:45:43 -0000 1.73 +++ target.h 19 May 2005 12:57:33 -0000 @@ -425,6 +425,7 @@ int to_magic; /* Need sub-structure for target machine related rather than comm related? */ + int (*to_reverse) (ptid_t, int); }; /* Magic number for checking ops size. If a struct doesn't end with this @@ -498,6 +499,16 @@ (*current_target.to_resume) (ptid, step, siggnal); \ } while (0) +/* Resume execution of the process TPID, but run in reverse. STEP + says whether to single-step or to run free. Returns -1 if the + target does not support reverse execution. */ + +#define target_reverse(ptid, step) \ + (current_target.to_reverse \ + ? (*current_target.to_reverse) (ptid, step) : -1) + +#define target_reserve_p() (current_target.to_reserve ? 1 : 0) + /* Wait for process pid to do something. PTID = -1 to wait for any pid to do something. Return pid of child, or -1 in case of error; store status through argument pointer STATUS. Note that it is ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 13:01 ` Johan Rydberg @ 2005-05-19 13:18 ` Daniel Jacobowitz 2005-05-19 13:47 ` Johan Rydberg 2005-05-20 10:37 ` Eli Zaretskii 1 sibling, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-19 13:18 UTC (permalink / raw) To: Johan Rydberg; +Cc: Dan Shearer, gdb On Thu, May 19, 2005 at 03:00:52PM +0200, Johan Rydberg wrote: > Here's a patch against CVS that implements the following commands: > > - rstep, rstepi > - rnext, rnexti Do you, and Virtutech, have copyright papers filed with the FSF? The GNU shell server is down at the moment, so I can't check myself. It would be best if we don't look at patches until that's taken care of. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 13:18 ` Daniel Jacobowitz @ 2005-05-19 13:47 ` Johan Rydberg 0 siblings, 0 replies; 80+ messages in thread From: Johan Rydberg @ 2005-05-19 13:47 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Dan Shearer, gdb Daniel Jacobowitz wrote: > Do you, and Virtutech, have copyright papers filed with the FSF? The > GNU shell server is down at the moment, so I can't check myself. It > would be best if we don't look at patches until that's taken care of. No. Can you send me the form, please? ~j ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 13:01 ` Johan Rydberg 2005-05-19 13:18 ` Daniel Jacobowitz @ 2005-05-20 10:37 ` Eli Zaretskii 2005-05-20 11:37 ` Andreas Schwab ` (2 more replies) 1 sibling, 3 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 10:37 UTC (permalink / raw) To: Johan Rydberg; +Cc: dan, gdb > Date: Thu, 19 May 2005 15:00:52 +0200 > From: Johan Rydberg <jrydberg@virtutech.com> > Cc: gdb@sources.redhat.com > > Here's a patch against CVS that implements the following commands: > > - rstep, rstepi > - rnext, rnexti > > The obvious commands "rcontinue" and "rfinished" are not yet > implemented, and therefor not included in this patch. The command > names are of course up for discussion. I don't mind these names; reverse-next etc. seem awkward, but rnext etc. are okay, I think. However, see my other comments in response to Daniel. > What I have done is add a new variable, step_direction, that can either > be STEP_DIR_FORWARD or STEP_DIR_REVERSE. I'd prefer STEP_FORWARD and STEP_BACKWARD. > To implement "rnext" I had to add a new target-specific function that > tries to figure out the address of the call instruction based on the > last executed instruction and the instruction to be executed, IF the > current instruction can be identified as a return insn. Sorry, I'm confused. Isn't it right that if I'm stepping backwards through code such as this: i += 1; foo (i); =>i = 0; where "=>" shows the current source line, then typing `rnext' once will get me to this: i += 1; =>foo (i); i = 0; which means I'm now before the CALL insn that calls `foo'? If so, what ``return insn'' were you talking about? If it's the return instruction that returns from `foo', then that insn is inside the code generatedfor `foo', which GDB won't see. What am I missing? > + add_com ("rnext", class_run, rnext_command, > + "Step program until it reaches the previous source line.\n\ "Go backwards until the program reaches the source line before the current one." > + add_com_alias ("rn", "rnext", class_run, 1); Do we want another alias called "previous"? > +extern enum step_direction_kind step_direction; Yuk! a global variable! > + if (step_direction == STEP_DIR_FORWARD) > + target_resume (resume_ptid, step, sig); > + else > + { > + target_reverse (resume_ptid, step); > + } I'd prefer that target_resume accepted the direction argument. Is there something that I'm missing that makes this hard or impossible? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 10:37 ` Eli Zaretskii @ 2005-05-20 11:37 ` Andreas Schwab 2005-05-20 13:18 ` Daniel Jacobowitz 2005-05-20 14:41 ` Eli Zaretskii 2005-05-20 12:22 ` Johan Rydberg 2005-05-20 13:14 ` Daniel Jacobowitz 2 siblings, 2 replies; 80+ messages in thread From: Andreas Schwab @ 2005-05-20 11:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Johan Rydberg, dan, gdb "Eli Zaretskii" <eliz@gnu.org> writes: >> Date: Thu, 19 May 2005 15:00:52 +0200 >> From: Johan Rydberg <jrydberg@virtutech.com> >> Cc: gdb@sources.redhat.com >> >> + add_com ("rnext", class_run, rnext_command, >> + "Step program until it reaches the previous source line.\n\ > > "Go backwards until the program reaches the source line before the > current one." The beginning or any part of the source line? While the latter is easy to determine (just step until the source line changes), the former is not very well defined, since the code for a source line can be intermixed with code from other source lines. On the other hand, just stepping until the source line changes is not very useful, since in extreme case you'll just step back a single insn if the previous command was a forward step and you won't really undo much of this step. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 11:37 ` Andreas Schwab @ 2005-05-20 13:18 ` Daniel Jacobowitz 2005-05-20 13:36 ` Fabian Cenedese 2005-05-20 14:41 ` Eli Zaretskii 1 sibling, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 13:18 UTC (permalink / raw) To: Andreas Schwab; +Cc: Eli Zaretskii, Johan Rydberg, dan, gdb On Fri, May 20, 2005 at 01:37:48PM +0200, Andreas Schwab wrote: > The beginning or any part of the source line? While the latter is easy to > determine (just step until the source line changes), the former is not > very well defined, since the code for a source line can be intermixed with > code from other source lines. On the other hand, just stepping until the > source line changes is not very useful, since in extreme case you'll just > step back a single insn if the previous command was a forward step and you > won't really undo much of this step. I suspect that the best we can do is back to the beginning of the previous fragment of a source line; step backwards until your PC matches the start of an entry in the line table. We need a coherent story for presenting fragmented lines to the user, but we don't have one - in either direction. That'll be as good as what we do going forwards. Of course it's possible that you enter the previous line in the middle: = line 1 label: line 1 some more line 1 a bit more = PC: line 2 line 2 I think the way to do this is to take advantage of the fact that reversible targets are generally (always? too early to tell perhaps) going to be repeatable. We can single-step backwards once, enter line 1, single step backwards again, still in line 1, single-step backwards again, we've gone too far, single-step forwards. Or, we could use a temporary bookmark. Single-step backwards once, enter line 1, place bookmark, single-step backwards again, good, update bookmark. Again, oops we're somewhere else, jump to bookmark and report a stop at label. Or implement both in case some target supports reverse execution without bookmarks. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 13:18 ` Daniel Jacobowitz @ 2005-05-20 13:36 ` Fabian Cenedese 2005-05-20 13:47 ` Daniel Jacobowitz 0 siblings, 1 reply; 80+ messages in thread From: Fabian Cenedese @ 2005-05-20 13:36 UTC (permalink / raw) To: gdb >Of course it's possible that you enter the previous line in the middle: > >= > line 1 >label: line 1 some more > line 1 a bit more >= >PC: line 2 > line 2 > >I think the way to do this is to take advantage of the fact that >reversible targets are generally (always? too early to tell perhaps) >going to be repeatable. We can single-step backwards once, enter line >1, single step backwards again, still in line 1, single-step backwards >again, we've gone too far, single-step forwards. Or, we could use a >temporary bookmark. Single-step backwards once, enter line 1, place >bookmark, single-step backwards again, good, update bookmark. Again, >oops we're somewhere else, jump to bookmark and report a stop at label. I followed this thread more out of curiosity than really need for this feature. That doesn't mean that we still couldn't use it one day :) I wondered though if this stepping backwards was more than just a simple setting of the program counter. If I step back over a i++, will it also get decremented? Or flags, they can't possibly be restored to what they were before e.g. a comparison, not without keeping a history. So these r-commands are merely other variants of "set next instruction", possibly with creating/releasing stack frames but without adjusting values according to the stepped over commands. Is this correct? Thanks bye Fabi ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 13:36 ` Fabian Cenedese @ 2005-05-20 13:47 ` Daniel Jacobowitz 0 siblings, 0 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 13:47 UTC (permalink / raw) To: Fabian Cenedese; +Cc: gdb On Fri, May 20, 2005 at 03:36:23PM +0200, Fabian Cenedese wrote: > I followed this thread more out of curiosity than really need for this feature. > That doesn't mean that we still couldn't use it one day :) > > I wondered though if this stepping backwards was more than just a simple > setting of the program counter. If I step back over a i++, will it also get > decremented? Or flags, they can't possibly be restored to what they > were before e.g. a comparison, not without keeping a history. So these > r-commands are merely other variants of "set next instruction", possibly > with creating/releasing stack frames but without adjusting values according > to the stepped over commands. Is this correct? No, that's not correct. That's why the only target that supports this at the moment is a simulator; it actually undoes the instructions and allows them to replay. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 11:37 ` Andreas Schwab 2005-05-20 13:18 ` Daniel Jacobowitz @ 2005-05-20 14:41 ` Eli Zaretskii 2005-05-20 22:14 ` Daniel Jacobowitz 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 14:41 UTC (permalink / raw) To: Andreas Schwab; +Cc: jrydberg, dan, gdb > From: Andreas Schwab <schwab@suse.de> > Cc: Johan Rydberg <jrydberg@virtutech.com>, dan@shearer.org, > gdb@sources.redhat.com > Date: Fri, 20 May 2005 13:37:48 +0200 > > > "Go backwards until the program reaches the source line before the > > current one." > > The beginning or any part of the source line? That's an interesting subtle point. At first I wanted to say "the former", but then I remembered the issue with moving a word forward and backward in editors. With some editors, such as Emacs, forward-word ends up one character _before_ the beginning of the next word, while backward-word ends up on the first character of the previous word. Other editors end up on the first character of a word with either forward or backward movement. So it could make sense for GDB to stop at the _last_ instruction of the previous source line when we move backwards by lines. The question is, will this be useful for the user. I'm not sure; perhaps they will want to skip all the code of the line and stop before its first instrcution, like "next" does. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 14:41 ` Eli Zaretskii @ 2005-05-20 22:14 ` Daniel Jacobowitz 0 siblings, 0 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 22:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Andreas Schwab, jrydberg, dan, gdb On Fri, May 20, 2005 at 05:37:17PM +0300, Eli Zaretskii wrote: > That's an interesting subtle point. At first I wanted to say "the > former", but then I remembered the issue with moving a word forward > and backward in editors. With some editors, such as Emacs, > forward-word ends up one character _before_ the beginning of the next > word, while backward-word ends up on the first character of the > previous word. Other editors end up on the first character of a word > with either forward or backward movement. More precisely, emacs' forward-word appears to put your cursor at the end of the current word, unless it was already there, in which case you go to the end of the next word. Similarly previous-word takes you to the beginning of the current word, unless you're already there. [The difference from what Eli wrote is purely pedantic - try it with multiple spaces between words. Not an issue for us :-)] > So it could make sense for GDB to stop at the _last_ instruction of > the previous source line when we move backwards by lines. The > question is, will this be useful for the user. I'm not sure; perhaps > they will want to skip all the code of the line and stop before its > first instrcution, like "next" does. Even the Emacs idea would work: back to the beginning of this source line. I think that beginning of the previous source line will be the most generally useful; the beginning of source lines is a more useful place for the debugger to go than the end, because the interface is much more apparent that the line "really" hasn't been execute yet. In any case, this is a subtle point - let's flag this subthread and make sure we write it down! And test it, if possible! :-) -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 10:37 ` Eli Zaretskii 2005-05-20 11:37 ` Andreas Schwab @ 2005-05-20 12:22 ` Johan Rydberg 2005-05-20 13:19 ` Daniel Jacobowitz 2005-05-20 14:12 ` Eli Zaretskii 2005-05-20 13:14 ` Daniel Jacobowitz 2 siblings, 2 replies; 80+ messages in thread From: Johan Rydberg @ 2005-05-20 12:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dan, gdb Eli Zaretskii wrote: >>What I have done is add a new variable, step_direction, that can either >>be STEP_DIR_FORWARD or STEP_DIR_REVERSE. > > I'd prefer STEP_FORWARD and STEP_BACKWARD. Ok. >>To implement "rnext" I had to add a new target-specific function that >>tries to figure out the address of the call instruction based on the >>last executed instruction and the instruction to be executed, IF the >>current instruction can be identified as a return insn. > > Sorry, I'm confused. Isn't it right that if I'm stepping backwards > through code such as this: > > i += 1; > foo (i); > =>i = 0; > > where "=>" shows the current source line, then typing `rnext' once > will get me to this: > > i += 1; > =>foo (i); > i = 0; > > which means I'm now before the CALL insn that calls `foo'? If so, > what ``return insn'' were you talking about? If it's the return > instruction that returns from `foo', then that insn is inside the code > generatedfor `foo', which GDB won't see. What am I missing? When you're single stepping backwards you can end up almost anywhere in the code. Take this scenario (in pseudo-PPC-assembler): (1) foo (i); 0: 80 7f 00 08 lwz r3,8(r31) 4: 48 00 00 01 bl X <foo> 8: nop (2) i = 0; c: 38 00 00 00 li r0,0 10: 90 1f 00 08 stw r0,8(r31) <foo>: .... 4c: 4e 80 00 20 blr You start with PC = c, and single steps backwards. You end up on the nop-insn. This is inside the single step range of line 1. So you single step another instruction backwards, and suddenly you stop at PC = 4c, which is far outside the stepping range. To detect if this was due to a "return from subroutine" you inspect the current instruction, blr, and if it happens to be return insn you can deduct the address of the call insn that called "foo". Since PowerPC does not have any delay slots, it's "safe" to assume that the insn _before_ the LAST stop_pc (== prev_pc) is the call insn. So to skip the subroutine call, you set a breakpoint on 0x4 (prev_pc - 4 = 8 - 4 = 4) and do a reverse-continue. When the breakpoint hits, you continue stepping until you reach the start of the stepping range. >>+ add_com ("rnext", class_run, rnext_command, >>+ "Step program until it reaches the previous source line.\n\ > > "Go backwards until the program reaches the source line before the > current one." Ok. > >>+ add_com_alias ("rn", "rnext", class_run, 1); > > Do we want another alias called "previous"? I think so, and maybe also "prev" and/or "pre". >>+extern enum step_direction_kind step_direction; > > Yuk! a global variable! I though it was OK since other variables in this context are global, such as step_range_start and step_frame_id. >>+ if (step_direction == STEP_DIR_FORWARD) >>+ target_resume (resume_ptid, step, sig); >>+ else >>+ { >>+ target_reverse (resume_ptid, step); >>+ } > > I'd prefer that target_resume accepted the direction argument. Is > there something that I'm missing that makes this hard or impossible? I don't think so. You just need to update more targets, though. ~j ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 12:22 ` Johan Rydberg @ 2005-05-20 13:19 ` Daniel Jacobowitz 2005-05-20 14:12 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 13:19 UTC (permalink / raw) To: Johan Rydberg; +Cc: Eli Zaretskii, dan, gdb On Fri, May 20, 2005 at 02:22:22PM +0200, Johan Rydberg wrote: > >>+extern enum step_direction_kind step_direction; > > > >Yuk! a global variable! > > I though it was OK since other variables in this context > are global, such as step_range_start and step_frame_id. This code goes back a long, long way. We're trying to improve it, which means not adding more globals :-) -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 12:22 ` Johan Rydberg 2005-05-20 13:19 ` Daniel Jacobowitz @ 2005-05-20 14:12 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 14:12 UTC (permalink / raw) To: Johan Rydberg; +Cc: dan, gdb > Date: Fri, 20 May 2005 14:22:22 +0200 > From: Johan Rydberg <jrydberg@virtutech.com> > Cc: dan@shearer.org, gdb@sources.redhat.com > > (1) foo (i); > 0: 80 7f 00 08 lwz r3,8(r31) > 4: 48 00 00 01 bl X <foo> > 8: nop > (2) i = 0; > c: 38 00 00 00 li r0,0 > 10: 90 1f 00 08 stw r0,8(r31) > > <foo>: > .... > 4c: 4e 80 00 20 blr > > You start with PC = c, and single steps backwards. You end up on > the nop-insn. This is inside the single step range of line 1. So > you single step another instruction backwards, and suddenly you > stop at PC = 4c I guess I don't understand how backwards movement works, because I thought stepping backwards over the branch instruction does _not_ take the branch, but rather rewinds the machine state to what it was before the branch instruction. Anyway, thanks for the explanations. > >>+ add_com_alias ("rn", "rnext", class_run, 1); > > > > Do we want another alias called "previous"? > > I think so, and maybe also "prev" and/or "pre". The additional aliases won't be necessary, since they both are unambiguous abbreviations of "previous". So they will work even if we don't define them as aliases. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 10:37 ` Eli Zaretskii 2005-05-20 11:37 ` Andreas Schwab 2005-05-20 12:22 ` Johan Rydberg @ 2005-05-20 13:14 ` Daniel Jacobowitz 2005-05-20 14:34 ` Eli Zaretskii 2005-05-20 15:40 ` Johan Rydberg 2 siblings, 2 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 13:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Johan Rydberg, dan, gdb Disclaimer: I have not looked at the code at all; I want to get the copyright assignment rolling first. On Fri, May 20, 2005 at 01:32:47PM +0300, Eli Zaretskii wrote: > > To implement "rnext" I had to add a new target-specific function that > > tries to figure out the address of the call instruction based on the > > last executed instruction and the instruction to be executed, IF the > > current instruction can be identified as a return insn. Johan, when I sketched out some algorithms for implementing these commands, I got the feeling that this was not a good way to do it. There are just too many ways to jump, and they can be pretty tricky to recognize on some architectures. PowerPC is easy, but it's a little more complicated to disassemble starting from the end of an instruction on ia32. Here's another one that requires absolutely no target support: - Detect reverse-step into a function - Set breakpoints at all entry points of the function; GDB doesn't support multiple entry points yet, really, so a breakpoint at the first instruction and a big fat comment is all this takes. - When you hit an entry point breakpoint, reverse-step once more. - If you have entered a different function, for instance via a reversed tail call, and you can still see the desired frame on the stack, then repeat. i.e. build reverse-next on top of reverse-finish. reverse-finish should take you to the intermediate caller in a tail call situation, not to the previous frame on the stack. Of course neither algorithm is robust in the case of stray jumps. Bookmarks and single-steps for that are the best we're going to get. > > + add_com ("rnext", class_run, rnext_command, > > + "Step program until it reaches the previous source line.\n\ > > "Go backwards until the program reaches the source line before the > current one." Johan used previous, you used backwards; let's figure out what we're calling the commands first :-P > > + add_com_alias ("rn", "rnext", class_run, 1); > > Do we want another alias called "previous"? I have no objection. > I'd prefer that target_resume accepted the direction argument. Is > there something that I'm missing that makes this hard or impossible? It should either be an argument, or a separate target hook as Michael proposed. No existing target supports it, so it would save us updating all targets to reject it. Which is just mechanical, so I don't feel strongly either way. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 13:14 ` Daniel Jacobowitz @ 2005-05-20 14:34 ` Eli Zaretskii 2005-05-20 15:40 ` Johan Rydberg 1 sibling, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 14:34 UTC (permalink / raw) To: Johan Rydberg, dan; +Cc: gdb > Date: Fri, 20 May 2005 09:13:48 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: Johan Rydberg <jrydberg@virtutech.com>, dan@shearer.org, > gdb@sources.redhat.com > > > > + add_com ("rnext", class_run, rnext_command, > > > + "Step program until it reaches the previous source line.\n\ > > > > "Go backwards until the program reaches the source line before the > > current one." > > Johan used previous, you used backwards; let's figure out what we're > calling the commands first :-P There's no connection between the doc strings and the discussion about the command names. I didn't use "backwards" instead of "previous", I used it instead of "Step program". That's because "step intil you reach the previous source line" does not say explicitly enough that we go backwards. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 13:14 ` Daniel Jacobowitz 2005-05-20 14:34 ` Eli Zaretskii @ 2005-05-20 15:40 ` Johan Rydberg 1 sibling, 0 replies; 80+ messages in thread From: Johan Rydberg @ 2005-05-20 15:40 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Eli Zaretskii, dan, gdb Daniel Jacobowitz wrote: > Johan, when I sketched out some algorithms for implementing these > commands, I got the feeling that this was not a good way to do it. > There are just too many ways to jump, and they can be pretty tricky to > recognize on some architectures. PowerPC is easy, but it's a little > more complicated to disassemble starting from the end of an instruction > on ia32. Here's another one that requires absolutely no target support: > [...] Yes, I'm well aware of this. > [...] > i.e. build reverse-next on top of reverse-finish. reverse-finish > should take you to the intermediate caller in a tail call situation, > not to the previous frame on the stack. This approach has also crossed my mind, and minimizing the need for target dependent code is worthwhile goal. I'll see if I can hack something up during the weekend. I guess the changes should not be that big. ~j ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 1:23 [discuss] Support for reverse-execution Dan Shearer 2005-05-19 13:01 ` Johan Rydberg @ 2005-05-20 10:47 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 10:47 UTC (permalink / raw) To: Dan Shearer; +Cc: gdb > Date: Thu, 19 May 2005 10:52:54 +0930 > From: Dan Shearer <dan@shearer.org> > > Imagine two new gdb commands, get-bookmark and goto-bookmark. > get-bookmark asks the simulator for a token which uniquely identifies > the current state of the system. goto-bookmark gives a token back to the > simulator and asks the simulator to load system state as it was at the > time of the bookmark. The token is an arbitary number that makes sense > to the particular simulator. Some might count in clock cycles, others in > milliseconds or maybe the number of the checkpoint that corresponds to > the state at that time. All gdb knows about is the value of the > bookmark. > > This gives a gdb user the capability to explore alternative futures > without a complicated interface. A sequence might be get-bookmark, > change a value, run for ten seconds. Break, goto-bookmark, try another > value and run for ten seconds. Like an infinite rewind-replay facility, > very helpful when part of the pain is getting the circumstances just > right for the bug to appear. > > It would be an interesting discussion to see how bookmarks could be > incorporated into the gdb framework. Sounds like a very useful feature. However, I think we need to support giving meaningful names to bookmarks, since a (more or less arbitrary) number used by the target is going to lack any mnemonic value. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution
@ 2005-05-21 15:53 Paul Schlie
0 siblings, 0 replies; 80+ messages in thread
From: Paul Schlie @ 2005-05-21 15:53 UTC (permalink / raw)
To: Russell Shaw, gdb
> Russell Shaw <rjshaw at netspace dot net dot au> writes:
> Yes, that's what i meant (every step). It could be configureable so
> that the policy can be set to every user-stop, every function call,
> or disabled alltogether. The idea is that you could run from main()
> until a segfault happens, then "back 10" and step thru the last few
> actions.
There's nothing inherently wrong with the strategy, as long as one
understands that the utility it provides can be deceptive; for example
given the following simple program fragment:
void foo(void)
{
x = the_real_problem();
for (int i = x, i != 0, ++i)
{
something();
}
}
foo(); // step from here.
... ; // to here.
It's clear that tracing and recording the last N states can easily
be consumed in uninteresting code.
A similar strategy may constrain the N full state traces/snapshots
to only entries into basic blocks, which both allows N to be smaller,
while simultaneously enabling a broader swipe of interesting locations
to recorded for subsequent inspection. This ideally either requires that
the compiled program be analyzed to apriority identify these entry points,
although a close approximation may be determined at runtime by only
recording state traces at points of control flow change; i.e. capture and
record state only upon a given condition, (typically when the PC != PC + 1,
for example), or may be generalized to any arbitrary set of "watch-point"
conditions; as an incremental nicety, not unlike the HW trace history buffer
support that some processors provide. (and could be enabled by GDB directly,
with or without target support)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 22:11 Michael Snyder 2005-05-20 23:32 ` Paul Schlie 0 siblings, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-20 22:11 UTC (permalink / raw) To: schlie, gdb >>> or presume the intelligence need be "remote" to GDB; >> >> We're not doing that either -- the user interface makes no >> assumption about the target interface. > > - Then there seems no need to define a reverse-xxxx set of commands > at the GDB/target-stub boundary (unless I misunderstand the purposed > of the earlier threads of dialog)? <tag-dont-take-this-as-criticism> The user interface makes no *assumption* about the target interface, but that doesn't mean that the target doesn't *also* need an interface. Both have been discussed in this thread, but they're not tied together. We have, for instance, discussed six or seven user commands (not counting bookmarks), but AFAIK only two target interface commands should be needed to support them -- "rc/bc" and "rs/bs". There's a third interface we've discussed too -- the interface between core-gdb and the target or back-end component (eg. but not limited to remote.c). We might, for instance, add a single new method to the target vector, eg. "to_resume_backwards" (or we might just add a direction parameter to the existing one). That method could then be added to, for instance, target sim. All that said, I'm not taking issue with your idea. I do think there might be a generic way for gdb to do something like dropping a checkpoint. I just don't think its mutually exclusive with this discussion. If you want to propose it in a separate thread, I'd be thrilled to talk about it. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 22:11 Michael Snyder @ 2005-05-20 23:32 ` Paul Schlie 0 siblings, 0 replies; 80+ messages in thread From: Paul Schlie @ 2005-05-20 23:32 UTC (permalink / raw) To: Michael Snyder, gdb > From: Michael Snyder <msnyder@redhat.com> >>>> or presume the intelligence need be "remote" to GDB; >>> >>> We're not doing that either -- the user interface makes no >>> assumption about the target interface. >> >> - Then there seems no need to define a reverse-xxxx set of commands >> at the GDB/target-stub boundary (unless I misunderstand the purposed >> of the earlier threads of dialog)? > > <tag-dont-take-this-as-criticism> > The user interface makes no *assumption* about the target > interface, but that doesn't mean that the target doesn't > *also* need an interface. Both have been discussed in this > thread, but they're not tied together. - I'd just caution against defining user commands which are in general much more difficult and expensive to support; i.e. defining any command which may specify a state which has not been previously likely recorded, as then it implies that the state needs to be unwound to the closest known point preceding it and then forward executed to the new desired state (which the simulation may have never "stopped" at before) More specifically for example, one may step past a function call, where the state preceding and after the call is now known, but the state preceding the previous instruction reverse-step-i may not be supported by the simulator naturally, and may require that the simulation be undone (which is always easiest) to the point preceding the call and then forward executed until the desired preceding instruction state is reached, etc. (Therefore an "undo/reverse" command is most likely the best basis for basic reverse simulation support, as it restricts reverse execution to only those points which the simulator had previously terminated it's simulation at previously; and other commands may be best only defined after such features are more broadly supported by at least a few simulators, and/or by GDB directly. Just as a thought.) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 21:59 Michael Snyder 0 siblings, 0 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:59 UTC (permalink / raw) To: dan, gdb >> (gdb) reverse-step >> # reverse-stepi once (or until we leave the *current* line) > > BTW, this bit is a little more complicated, because we might go > to another frame. So we might have to do some reverse-finish's > stacked in there. Absolutely -- I just wanted to focus on the one point. > I think infrun will need some serious cleaning > up to pull this off. infrun *always* needs serious cleaning up. ;-) Seriously, though, we'll have to add some new state, but I think it's doable without major rewriting. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 21:51 Michael Snyder 2005-05-21 9:44 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:51 UTC (permalink / raw) To: gdb >>> Would not it be better to have a single "reverse" command which >>> puts the debugger in "reverse" mode -- making step/stepi/next/nexti >>> go backward. >> >> Daniel, I rest my case ;-) > > I don't rest mine :-) I admit I was a little surprised to see > someone else suggest it, but I still think it's an awful idea as > a user interface. Make me a third person who thought of it independantly. Look at it this way -- once we've implemented the reverse-x command set, adding this would be trivial; just a single set/show mode variable. Then we could evaluate both, or even leave it to the user to choose. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 21:51 Michael Snyder @ 2005-05-21 9:44 ` Eli Zaretskii 0 siblings, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-21 9:44 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb > Date: Fri, 20 May 2005 14:51:17 -0700 > From: Michael Snyder <msnyder@redhat.com> > > Make me a third person who thought of it independantly. > > Look at it this way -- once we've implemented the reverse-x > command set, adding this would be trivial; just a single > set/show mode variable. Then we could evaluate both, or even > leave it to the user to choose. The problem is, once we implement such a mode, the word "reverse" becomes ambiguous: it no longer unambiguously says that we go backwards. That prospect was the original reason I mentioned the possibility of introducing such a mode in the future. And that was the reason I still think it's better, at least in principle, to say "backwards" or "back", because that's unambiguous. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 21:44 Michael Snyder 0 siblings, 0 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:44 UTC (permalink / raw) To: gdb, ghost > Would not it be better to have a single "reverse" command which > puts the debugger in "reverse" mode -- making step/stepi/next/nexti > go backward. > > This might be handier for UI -- after all "step" can be abbreviated > as 's', but reverse-step can't be abbreviated. This might be better > in GUI too -- instead of doubling the number of "step" commands > you'd have a single "gear" switch, that can be in either "forward" > or "reverse" position. > > - Volodya I'm certainly not opposed to that, although I lean a bit more toward the separate "analogue" commands. Fortunately, command interface is easy to implement. Maybe we will float several independant patches that each implement a different CLI to the same functionality, so we can try them all out and get a feel for them. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 21:25 Michael Snyder 0 siblings, 0 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:25 UTC (permalink / raw) To: Dan Shearer, gdb > In general I really like the idea of GDB better catering to > non-remote simulators. You'll notice that almost none of the > whole-system simulators in the free software world have > integrated debugging and I'd >love to make that easier. Traditionally, that's how we used to do it, and we still can (see src/sim). I think we've tended in the direction of letting the sim be a separate program because sims like SID are so big. Linking them in to gdb would make both huge. The approach of using the remote protocol is very flexible. The debugger and the sim can be running on the same host, or on opposite sides of the planet. If they're on the same host, running packets thru a socket really doesn't slow us down all that much. But there is a function-call interface for linking gdb to a sim if its wanted. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 21:16 Michael Snyder 2005-05-20 21:31 ` Daniel Jacobowitz 2005-05-21 9:39 ` Eli Zaretskii 0 siblings, 2 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:16 UTC (permalink / raw) To: Daniel Jacobowitz, gdb >> It would be an interesting discussion to see how bookmarks could be >> incorporated into the gdb framework. > > Sounds like a very useful feature. However, I think we need to > support giving meaningful names to bookmarks, since a (more or less > arbitrary) number used by the target is going to lack any mnemonic > value. How about counting numbers, like we do with breakpoints? (gdb) get-bookmark Bookmark #1, line 12, foo.c == <quasi-random-identifier> (gdb) continue Breakpoint 5, line 144, grbx.c (gdb) info bookmarks Bookmark ID Location 1 <###> foo.c line 12 (gdb) goto-bookmark 1 Line 12, foo.c (bookmark <quasi-random-identifier>) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 21:16 Michael Snyder @ 2005-05-20 21:31 ` Daniel Jacobowitz 2005-05-21 9:39 ` Eli Zaretskii 1 sibling, 0 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 21:31 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb On Fri, May 20, 2005 at 02:16:29PM -0700, Michael Snyder wrote: > >> It would be an interesting discussion to see how bookmarks could be > >> incorporated into the gdb framework. > > > > Sounds like a very useful feature. However, I think we need to > > support giving meaningful names to bookmarks, since a (more or less > > arbitrary) number used by the target is going to lack any mnemonic > > value. > > How about counting numbers, like we do with breakpoints? > > (gdb) get-bookmark > Bookmark #1, line 12, foo.c == <quasi-random-identifier> > (gdb) continue > Breakpoint 5, line 144, grbx.c > (gdb) info bookmarks > Bookmark ID Location > 1 <###> foo.c line 12 > (gdb) goto-bookmark 1 > Line 12, foo.c (bookmark <quasi-random-identifier>) I think Eli's right... why not let the user give them real names? We can give them sequential numbers, too, if we want. I'd probably end up naming all my bookmarks "q", cause that's the sort of person I am, but... -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 21:16 Michael Snyder 2005-05-20 21:31 ` Daniel Jacobowitz @ 2005-05-21 9:39 ` Eli Zaretskii 2005-05-23 18:19 ` Michael Snyder 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-21 9:39 UTC (permalink / raw) To: Michael Snyder; +Cc: drow, gdb > Date: Fri, 20 May 2005 14:16:29 -0700 > From: Michael Snyder <msnyder@redhat.com> > > > Sounds like a very useful feature. However, I think we need to > > support giving meaningful names to bookmarks, since a (more or less > > arbitrary) number used by the target is going to lack any mnemonic > > value. > > How about counting numbers, like we do with breakpoints? That might be okay as well, but I consider the method of numbering breakpoints as not an ideal one, either. It's impossible to manage more than 3 breakpoints without "info breakpoints". More mnemonic names could have allowed us to know what breakpoint we need to use without consulting the table displayed by "info breakpoints". ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 9:39 ` Eli Zaretskii @ 2005-05-23 18:19 ` Michael Snyder 0 siblings, 0 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-23 18:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: drow, gdb Eli Zaretskii wrote: >>Date: Fri, 20 May 2005 14:16:29 -0700 >>From: Michael Snyder <msnyder@redhat.com> >> >> > Sounds like a very useful feature. However, I think we need to >> > support giving meaningful names to bookmarks, since a (more or less >> > arbitrary) number used by the target is going to lack any mnemonic >> > value. >> >>How about counting numbers, like we do with breakpoints? > > > That might be okay as well, but I consider the method of numbering > breakpoints as not an ideal one, either. It's impossible to manage > more than 3 breakpoints without "info breakpoints". More mnemonic > names could have allowed us to know what breakpoint we need to use > without consulting the table displayed by "info breakpoints". OK, then maybe we should make this a general feature -- add a name field for breakpoints, tracepoints, checkpoint/bookmarks, and in general such things as we have such lists for. Looking ahead, people may one day want to give names to threads, or even sets-of-threads. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 21:11 Michael Snyder 2005-05-20 21:27 ` Daniel Jacobowitz 0 siblings, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:11 UTC (permalink / raw) To: gdb, Eli Zaretskii, Daniel Jacobowitz In regards to the question "where does a reverse-step put you?" (ie. at the beginning of a line, or somewhere in the line): > Sorry, I'm confused. Isn't it right that if I'm stepping > backwards through code such as this: > > i += 1; > foo (i); > =>i = 0; > > where "=>" shows the current source line, then typing `rnext' > once will get me to this: > > i += 1; > =>foo (i); > i = 0; > > which means I'm now before the CALL insn that calls `foo'? I agree with this interpretation. If I am a user (and I am), and I were to say: (gdb) step (gdb) reverse-step (or whatever) I would expect to be back where I started, ie. at the *beginning* of the original line. Dan J. has said that we might need to reverse-stepi until we've gone back one too many, and then do a forward step. I agree. In fact, I think it will be necessary to do the following: (gdb) reverse-step # reverse-stepi once (or until we leave the *current* line) # now establish the step-range start and end (prev line) # reverse-stepi until we leave the prev line # stepi once to get back to the desired line. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 21:11 Michael Snyder @ 2005-05-20 21:27 ` Daniel Jacobowitz 0 siblings, 0 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 21:27 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb, Eli Zaretskii [Michael, if you get a chance, please update your address book; I'm not @mvista.com any more.] On Fri, May 20, 2005 at 02:11:25PM -0700, Michael Snyder wrote: > I agree with this interpretation. If I am a user (and I am), > and I were to say: > (gdb) step > (gdb) reverse-step (or whatever) > I would expect to be back where I started, ie. at the > *beginning* of the original line. > > Dan J. has said that we might need to reverse-stepi until > we've gone back one too many, and then do a forward step. > I agree. In fact, I think it will be necessary to do > the following: After reading this a couple of times, I'm pretty sure you're right. Consider: line: foo line2: inc $r1 cmp $r1, 64 bne line line3: bar # $pc points here Reverse stepi from the inc may go to the bne, but we want to stop when reverse stepi from the inc would go to the foo instead. We don't have a lot of opportunity to make sure we're really where we want to be when we're going forwards. When we're going backwards, though, we do. Let's use it! > (gdb) reverse-step > # reverse-stepi once (or until we leave the *current* line) BTW, this bit is a little more complicated, because we might go to another frame. So we might have to do some reverse-finish's stacked in there. I think infrun will need some serious cleaning up to pull this off. > # now establish the step-range start and end (prev line) > # reverse-stepi until we leave the prev line > # stepi once to get back to the desired line. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 19:02 Michael Snyder 2005-05-20 20:43 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-20 19:02 UTC (permalink / raw) To: gdb; +Cc: Eli Zaretskii >> +extern enum step_direction_kind step_direction; > > Yuk! a global variable! That's entirely typical, Eli, for a "set/show" mode variable. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 19:02 Michael Snyder @ 2005-05-20 20:43 ` Eli Zaretskii 2005-05-20 21:03 ` Michael Snyder 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 20:43 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb > Date: Fri, 20 May 2005 12:02:26 -0700 > From: Michael Snyder <msnyder@redhat.com> > CC: Eli Zaretskii <eliz@is.elta.co.il> > > >> +extern enum step_direction_kind step_direction; > > > > Yuk! a global variable! > > That's entirely typical, Eli, for a "set/show" mode variable. Except that this wasn't a set/show mode variable at all. It was a bona fide argument to be passed to target_resume. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 20:43 ` Eli Zaretskii @ 2005-05-20 21:03 ` Michael Snyder 0 siblings, 0 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-20 21:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb Eli Zaretskii wrote: >>Date: Fri, 20 May 2005 12:02:26 -0700 >>From: Michael Snyder <msnyder@redhat.com> >>CC: Eli Zaretskii <eliz@is.elta.co.il> >> >> >> +extern enum step_direction_kind step_direction; >> > >> > Yuk! a global variable! >> >>That's entirely typical, Eli, for a "set/show" mode variable. > > > Except that this wasn't a set/show mode variable at all. It was a > bona fide argument to be passed to target_resume. Oh, sorry. Guess I was thinking ahead to the idea of having a user-setable direction mode. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution @ 2005-05-20 15:49 Paul Schlie 2005-05-20 17:41 ` Dan Shearer 2005-05-20 20:58 ` Michael Snyder 0 siblings, 2 replies; 80+ messages in thread From: Paul Schlie @ 2005-05-20 15:49 UTC (permalink / raw) To: Daniel Jacobowitz, Eli Zaretskii, Michael Snyder, gdb Alternatively to attempting to specify an interface to a lone commercial reversible simulator, or presume the intelligence need be "remote" to GDB; I wonder if it may be more sensible to consider initially defining the basic generic facilities by which GDB may directly support undoable/reversible execution, and checkpoint features. More specifically, as ISA semantics do not generally have deterministic reciprocal semantics, it's only possible to support reverse execution by literally being able to either maintain a list of all state changes associated with each instruction/command's execution and unwind them, and then optionally proceed forward again. Therefore it seems likely sufficient to initially begin by defining support for the following core facilities: Basic GDB support for check pointing and reverse execution: - enable-checkpoints: initializes machine state and program memory to all 0's upon prior to program startup/initialization. (see below) - save-checkpoint [Optional-Name] => checkpoint [N [Optional-Name]], saves a diff between the programs present state and it's previous state, and marks the current undo-state diff (see below) as being equivalent to this checkpoint. - restore-checkpoint [N | Opional-Name]; sets machine and memory state to the cumulative difference between all 0's and the designated checkpoint diff. [this is insensitive to the target's stub supporting state-diff, as GBD is responsible for storing and computing state-point restores on behalf of the target] - enable-undo/reverse: sets flag to request state-diff from target stub upon (step, next, etc.) commands. - (step, next, etc.): as normal, but requests the state-diff from the target stub between successive command executions if reverse-execution flag is enabled. (This may also be supported without target stub support for state-diff, as GDB has direct access to both the target's machine state, and memory state; although target stubs may likely be capable of more efficient diff's if they are capable of tracking memory updates more efficiently than simply looking after the fact.) - undo/reverse: undoes/reverses the previously issued command, by un-diff'ing the present machine and memory state with the previously returned diff. (which is likely sufficient and substantially more time and resource efficient than attempting to otherwise effectively single-step record all intervening individual instruction execution diff's, which could also be enabled if desired, although likely not necessary in general.) Basic Target stub facilities to improve reverse execution efficiently: - state-diff: the target returns the diff between the target's present state and it's previous state, which may be used if available in lieu of GDB directly calculating machine and memory state diffs, but would likely only be substantially more efficient if the target stub were capable of more efficiently tracking and accumulating diffs by directly monitoring memory state changes, rather than determining them after the fact, as may be done likely efficiently by a target simulator and then simply communicated by publishing the cumulative diffs as requested by GDB; which seems nice and simple, and minimally invasive.) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 15:49 Paul Schlie @ 2005-05-20 17:41 ` Dan Shearer 2005-05-20 22:01 ` Paul Schlie 2005-05-20 20:58 ` Michael Snyder 1 sibling, 1 reply; 80+ messages in thread From: Dan Shearer @ 2005-05-20 17:41 UTC (permalink / raw) To: Paul Schlie; +Cc: gdb On Fri, May 20, 2005 at 11:49:08AM -0400, Paul Schlie wrote: > Rather than... presume the intelligence need be "remote" to GDB; : > I wonder if it may be more sensible to consider initially defining the basic > generic facilities by which GDB may directly support undoable/reversible > execution, and checkpoint features. An alternative point of view: right now nobody has deep experience with reversible debugging and so it seems a little early to make across-the-board structure changes based on limited understanding. In the longer term yes, GDB should be able to debug with a sense of direction and time. But I think it will take quite a bit of experimentation before we have a clear model of how to do this, and the only way I can think of for both having a reversible GDB and not touching GDB too much is by considering remote targets first. In general I really like the idea of GDB better catering to non-remote simulators. You'll notice that almost none of the whole-system simulators in the free software world have integrated debugging and I'd love to make that easier. It's just that the reversibility property is new and I think it will take some getting used to. > More specifically, as ISA semantics do not generally have deterministic > reciprocal semantics, What do you mean by "ISA" in this context? > Therefore it seems likely sufficient to initially begin by defining > support for the following core facilities: > > Basic GDB support for check pointing and reverse execution: > > - enable-checkpoints: initializes machine state and program memory to > all 0's upon prior to program startup/initialization. (see below) Isn't this getting out of scope for GDB's current design? If you're going to provide this meta-system command to the simulator why not provide others, like "load-image-file <filename>" to initialise the simulator or "enable-skip-idle" to make the simulator skip idle loops and other simulator-specific commands. Again, I like the idea of making GDB closer to simulated environments, but I think it probably needs to be a specific choice to do this rather than just as a byproduct of supporting reversibility. > - (step, next, etc.): as normal, but requests the state-diff from the > target stub between successive command executions if reverse-execution > flag is enabled. (This may also be supported without target stub support > for state-diff, as GDB has direct access to both the target's machine > state, and memory state; although target stubs may likely be capable > of more efficient diff's if they are capable of tracking memory updates > more efficiently than simply looking after the fact.) Can you explain what kind of a facility you imagine GDB might have to support doing diffs inherently? > Basic Target stub facilities to improve reverse execution efficiently: > > - state-diff: the target returns the diff between the target's present > state and it's previous state, which may be used if available in lieu > of GDB directly calculating machine and memory state diffs, but would > likely only be substantially more efficient if the target stub were > capable of more efficiently tracking and accumulating diffs by directly > monitoring memory state changes, rather than determining them after > the fact, as may be done likely efficiently by a target simulator and > then simply communicated by publishing the cumulative diffs as requested > by GDB; which seems nice and simple, and minimally invasive.) Unless I've misunderstood you are proposing that GDB have the ability to accept and manipulate entire memory state and diffs of memory state. This is quite a large chunk of new functionality. -- Dan Shearer dan@shearer.org ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 17:41 ` Dan Shearer @ 2005-05-20 22:01 ` Paul Schlie 2005-05-20 22:08 ` Daniel Jacobowitz 0 siblings, 1 reply; 80+ messages in thread From: Paul Schlie @ 2005-05-20 22:01 UTC (permalink / raw) To: Dan Shearer; +Cc: gdb > From: Dan Shearer <dan@shearer.org> >> On Fri, May 20, 2005 at 11:49:08AM -0400, Paul Schlie wrote: >> Rather than... presume the intelligence need be "remote" to GDB; > : >> I wonder if it may be more sensible to consider initially defining the basic >> generic facilities by which GDB may directly support undoable/reversible >> execution, and checkpoint features. > > An alternative point of view: right now nobody has deep experience with > reversible debugging and so it seems a little early to make > across-the-board structure changes based on limited understanding. - Actually I have intimate familiarity with simulation architecture and check-pointed reversible simulation. > In the longer term yes, GDB should be able to debug with a sense of > direction and time. But I think it will take quite a bit of experimentation > before we have a clear model of how to do this, and the only way I can think > of for both having a reversible GDB and not touching GDB too much is by > considering remote targets first. - Then you'll end up with nothing more than an interface to a propriety simulator, which doesn't seem like a good goal or approach for GDB. > In general I really like the idea of GDB better catering to non-remote > simulators. You'll notice that almost none of the whole-system > simulators in the free software world have integrated debugging and I'd > love to make that easier. It's just that the reversibility property is > new and I think it will take some getting used to. - I've basically already described how to do this in a generalized way. >> More specifically, as ISA semantics do not generally have deterministic >> reciprocal semantics, > > What do you mean by "ISA" in this context? - The sum total of all defined instructions semantic effects on machine and program data memory state. >> Therefore it seems likely sufficient to initially begin by defining >> support for the following core facilities: >> >> Basic GDB support for check pointing and reverse execution: >> >> - enable-checkpoints: initializes machine state and program memory to >> all 0's upon prior to program startup/initialization. (see below) > > Isn't this getting out of scope for GDB's current design? If you're > going to provide this meta-system command to the simulator why not > provide others, like "load-image-file <filename>" to initialise the > simulator or "enable-skip-idle" to make the simulator skip idle loops > and other simulator-specific commands. > > Again, I like the idea of making GDB closer to simulated environments, > but I think it probably needs to be a specific choice to do this rather > than just as a byproduct of supporting reversibility. - What's interesting is that "reverse" execution is actually very simple, once it's understood that you can't generally "reverse execute", but only back-up to a previous state; then it becomes clear that all that's necessary is to define a method by which state-differences are extracted, and then unwound, on an command by command basis, not dissimilarly to how "undo" is typically handled by text editors, etc. (one may try to do fancier things, but will be found not to likely be worth it.) >> - (step, next, etc.): as normal, but requests the state-diff from the >> target stub between successive command executions if reverse-execution >> flag is enabled. (This may also be supported without target stub support >> for state-diff, as GDB has direct access to both the target's machine >> state, and memory state; although target stubs may likely be capable >> of more efficient diff's if they are capable of tracking memory updates >> more efficiently than simply looking after the fact.) > > Can you explain what kind of a facility you imagine GDB might have to > support doing diffs inherently? - How about simply defining that the diff-address/diff-extent/diff-values be recorded in an indexed file for any differences found between the previous memory state, and the now current memory state; where the previous memory state is stored in a sequential file, and the present is obtained from the target, then computing the diff, and saving the current memory state in the file replacing the previously defined previous memory state. >> Basic Target stub facilities to improve reverse execution efficiently: >> >> - state-diff: the target returns the diff between the target's present >> state and it's previous state, which may be used if available in lieu >> of GDB directly calculating machine and memory state diffs, but would >> likely only be substantially more efficient if the target stub were >> capable of more efficiently tracking and accumulating diffs by directly >> monitoring memory state changes, rather than determining them after >> the fact, as may be done likely efficiently by a target simulator and >> then simply communicated by publishing the cumulative diffs as requested >> by GDB; which seems nice and simple, and minimally invasive.) > > Unless I've misunderstood you are proposing that GDB have the ability to > accept and manipulate entire memory state and diffs of memory state. > This is quite a large chunk of new functionality. - It may be a lot of memory, but it's just a diff between two sequential data streams (as roughly described above if done by bruit force; which is likely fine for many embedded targets; and the only option if it's not a "simulated" target). ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 22:01 ` Paul Schlie @ 2005-05-20 22:08 ` Daniel Jacobowitz 2005-05-20 22:43 ` Paul Schlie 0 siblings, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 22:08 UTC (permalink / raw) To: Paul Schlie; +Cc: Dan Shearer, gdb On Fri, May 20, 2005 at 06:01:44PM -0400, Paul Schlie wrote: > > From: Dan Shearer <dan@shearer.org> > > In the longer term yes, GDB should be able to debug with a sense of > > direction and time. But I think it will take quite a bit of experimentation > > before we have a clear model of how to do this, and the only way I can think > > of for both having a reversible GDB and not touching GDB too much is by > > considering remote targets first. > > - Then you'll end up with nothing more than an interface to a propriety > simulator, which doesn't seem like a good goal or approach for GDB. This argument is so bogus that I need to call you on it. You end up with a reasonable interface to _any_ simulator, whether proprietary or not. The details of an efficient implementation will be obviously dependent on the simulator's state and implementation. I am inclined to agree with the posted proposals that the implementation of reverse-stepi should be opaque to GDB, at least for now. The performance of shuffling state diffs over the remote protocol - or even just references to them - would be horrid. It also means that GDB will be limited to a particular class of implementations of reversible simulation instead of the concept of reversible simulation. You're describing something which may be interesting, someday. Do feel welcome to implement it; we'll be glad to help. I don't think that it's inherently more appropriate than the proposed interface, though. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 22:08 ` Daniel Jacobowitz @ 2005-05-20 22:43 ` Paul Schlie 2005-05-21 0:58 ` Daniel Jacobowitz 0 siblings, 1 reply; 80+ messages in thread From: Paul Schlie @ 2005-05-20 22:43 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Dan Shearer, gdb > From: Daniel Jacobowitz <drow@false.org> >> On Fri, May 20, 2005 at 06:01:44PM -0400, Paul Schlie wrote: >>> From: Dan Shearer <dan@shearer.org> >>> In the longer term yes, GDB should be able to debug with a sense of >>> direction and time. But I think it will take quite a bit of experimentation >>> before we have a clear model of how to do this, and the only way I can think >>> of for both having a reversible GDB and not touching GDB too much is by >>> considering remote targets first. >> >> - Then you'll end up with nothing more than an interface to a propriety >> simulator, which doesn't seem like a good goal or approach for GDB. > > This argument is so bogus that I need to call you on it. You end up > with a reasonable interface to _any_ simulator, whether proprietary or > not. The details of an efficient implementation will be obviously > dependent on the simulator's state and implementation. - Which is fully your right to claim/believe; however noting the absence of non-proprietary simulators with these capabilities (it's a little unclear how one can presume that interfaces are likely most ideally necessary or appropriate; and simply note that register and memory state by definition is program state, which GDB already has direct access to). > I am inclined to agree with the posted proposals that the > implementation of reverse-stepi should be opaque to GDB, at least for > now. The performance of shuffling state diffs over the remote protocol > - or even just references to them - would be horrid. It also means > that GDB will be limited to a particular class of implementations of > reversible simulation instead of the concept of reversible simulation. - There's no magic, defining a interface for a non-existent simulator doesn't yield a functional solution, and given the absents of knowledge of what that the "typical" simulator's interface presumptions are seems a little premature to define in lieu of a solution. As an aside and personal opinion, I happen believe it's not likely good form to define "opaque" interfaces to non-FSF tools without at least simultaneously implementing a non-opaque/proprietary solution (which is I guess the same philosophical problem that I have with the sourcing of any information, including potentially proprietary extended register/ISA definitions through an "opaque" interface/wall). > You're describing something which may be interesting, someday. Do feel > welcome to implement it; we'll be glad to help. I don't think that > it's inherently more appropriate than the proposed interface, though. - It was just offered as a potential alternative based on a different philosophical view; which I may consider doing something with as time and inclination may allow, and do appreciate the offer for assistance if/when that time comes. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 22:43 ` Paul Schlie @ 2005-05-21 0:58 ` Daniel Jacobowitz 2005-05-21 1:42 ` Paul Schlie 0 siblings, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-21 0:58 UTC (permalink / raw) To: Paul Schlie; +Cc: Dan Shearer, gdb On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote: > - Which is fully your right to claim/believe; however noting the absence > of non-proprietary simulators with these capabilities (it's a little > unclear how one can presume that interfaces are likely most ideally > necessary or appropriate; and simply note that register and memory state > by definition is program state, which GDB already has direct access to). That is incorrect. There can be considerably more state. For instance, I understand from Dan's explanation that Simics will reply external interrupt sources - at the same clock cycles where they would otherwise have occurred. > As an aside and personal opinion, I happen believe it's not likely good > form to define "opaque" interfaces to non-FSF tools without at least > simultaneously implementing a non-opaque/proprietary solution (which is > I guess the same philosophical problem that I have with the sourcing of > any information, including potentially proprietary extended register/ISA > definitions through an "opaque" interface/wall). It's no more opaque than the continue command is opaque. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 0:58 ` Daniel Jacobowitz @ 2005-05-21 1:42 ` Paul Schlie 2005-05-21 1:53 ` Daniel Jacobowitz 0 siblings, 1 reply; 80+ messages in thread From: Paul Schlie @ 2005-05-21 1:42 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Dan Shearer, gdb > From: Daniel Jacobowitz <drow@false.org> >> On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote: >> - Which is fully your right to claim/believe; however noting the absence >> of non-proprietary simulators with these capabilities (it's a little >> unclear how one can presume that interfaces are likely most ideally >> necessary or appropriate; and simply note that register and memory state >> by definition is program state, which GDB already has direct access to). > > That is incorrect. There can be considerably more state. For > instance, I understand from Dan's explanation that Simics will reply > external interrupt sources - at the same clock cycles where they would > otherwise have occurred. - Supporting HW co-simulation is certainly interesting, but fundamentally no different; it only extends the definition of "state" typically by literally exposing some of the logical CPU/I/O/Peripheral/outside-world state in various levels of details depending on the goals of the model, and/or simulation itself. (but would guess likely beyond the near term goals of attempting to enable GDB support for basic reversible execution?) [And suspect you'll find that most HW savvy simulation environments have very limited if any support for "reversible" simulation, beyond checkpoint-restart. As on a cycle by cycle basis, tracking and recording incremental state changes would typically cripple the simulation, and potentially even exhaust disk storage for complex models, but limited forms do exist, and are useful.] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 1:42 ` Paul Schlie @ 2005-05-21 1:53 ` Daniel Jacobowitz 2005-05-21 1:56 ` Daniel Jacobowitz 2005-05-21 14:13 ` Paul Schlie 0 siblings, 2 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-21 1:53 UTC (permalink / raw) To: Paul Schlie; +Cc: Dan Shearer, gdb On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote: > - Supporting HW co-simulation is certainly interesting, but fundamentally > no different; it only extends the definition of "state" typically by > literally exposing some of the logical CPU/I/O/Peripheral/outside-world > state in various levels of details depending on the goals of the model, > and/or simulation itself. (but would guess likely beyond the near term > goals of attempting to enable GDB support for basic reversible execution?) Why should it be? This is another reason that I consider the simulator a perfectly reasonable place to have the logic. Frank has contributed that sid would more readily support the sort of snapshot-based reconstruction that you're talking about (thanks Frank). I think that allowing the target to provide infrun with a view in which "single step backwards" is possible and then implementing that under the covers in the target stack would still be the way to go - but I don't think that's a legitimate objection to supporting a smart simulator which does it internally. When someone implements reversible debugging in a free simulator and wants to integrate that with GDB, they'll have the choice of doing the remaining steps in their simulator or in GDB. > [And suspect you'll find that most HW savvy simulation environments have > very limited if any support for "reversible" simulation, beyond > checkpoint-restart. As on a cycle by cycle basis, tracking and recording > incremental state changes would typically cripple the simulation, and > potentially even exhaust disk storage for complex models, but limited > forms do exist, and are useful.] You might want to read the papers on the specific simulator we're discussing using as a starting point; you can find the white paper on Virtutech's web site. Under the covers, of course, it's probably checkpoint based. But it's efficient, automatic checkpointing such that it can provide a reversible view over useful periods of time. Complete with "HW savvy" details. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 1:53 ` Daniel Jacobowitz @ 2005-05-21 1:56 ` Daniel Jacobowitz 2005-05-21 15:03 ` Paul Schlie 2005-05-21 14:13 ` Paul Schlie 1 sibling, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-21 1:56 UTC (permalink / raw) To: Paul Schlie, Dan Shearer, gdb On Fri, May 20, 2005 at 09:52:45PM -0400, Daniel Jacobowitz wrote: > Frank has contributed that sid would more readily support the sort of > snapshot-based reconstruction that you're talking about (thanks Frank). > I think that allowing the target to provide infrun with a view in which > "single step backwards" is possible and then implementing that under > the covers in the target stack would still be the way to go - but I > don't think that's a legitimate objection to supporting a smart > simulator which does it internally. BTW, a thought to consider - again, one which will only be interesting when there's a system to which it applies. What most of these single-stepping commands want to do, in the absence of watchpoints, is see the PC sequence over a timeline, choose a stopping state, and go to that state. For some simulator it may be substantially more efficient to just ask the target for a history of PC values for some number of cycles, all at once, and then tell it which one of those we're interested in. That would work for reverse-next, for example. I don't know the level of computation involved in these snapshots in Simics; perhaps an intelligent simulator, when told to go backwards, would reconstruct a series of "frames" all at once and cache them, so this is a non-issue. For some other simulator not yet available, perhaps it's not. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 1:56 ` Daniel Jacobowitz @ 2005-05-21 15:03 ` Paul Schlie 0 siblings, 0 replies; 80+ messages in thread From: Paul Schlie @ 2005-05-21 15:03 UTC (permalink / raw) To: Daniel Jacobowitz, Dan Shearer, gdb > From: Daniel Jacobowitz <drow@false.org> >> On Fri, May 20, 2005 at 09:52:45PM -0400, Daniel Jacobowitz wrote: >> Frank has contributed that sid would more readily support the sort of >> snapshot-based reconstruction that you're talking about (thanks Frank). >> I think that allowing the target to provide infrun with a view in which >> "single step backwards" is possible and then implementing that under >> the covers in the target stack would still be the way to go - but I >> don't think that's a legitimate objection to supporting a smart >> simulator which does it internally. > > BTW, a thought to consider - again, one which will only be interesting > when there's a system to which it applies. > > What most of these single-stepping commands want to do, in the absence > of watchpoints, is see the PC sequence over a timeline, choose a > stopping state, and go to that state. For some simulator it may be > substantially more efficient to just ask the target for a history of PC > values for some number of cycles, all at once, and then tell it which > one of those we're interested in. That would work for reverse-next, > for example. - Tracing a subset of the states is one thing, tracing and recording all states can be quite another; where like most things, the significance of "some" vs. "all" is relative to the detail inherent in the model of the system being simulated. In the simplest ISA simulation case without attempting to model a complex HW world around the processor in detail, it's not necessarily unreasonable to record all of the most recent N cycle states, presuming N is large enough to be useful; although tracing anything likely reduces simulation performance by at least a factor of 10 vs. tracing nothing between termination points, it's not likely a big deal when a typical simulation interval may only otherwise require a fraction of a second, but can easily become a big deal when the complexity of a simulation may otherwise be measured in minutes (as the very nature of interactive debugging implies some minimal latency so the pilot doesn't feel compelled to take naps while attempting to interactively analyze their system's behavior between supposedly interactive requests; as otherwise things become counterproductive, as the pilot can easily loose their train of thought). > I don't know the level of computation involved in these snapshots in > Simics; perhaps an intelligent simulator, when told to go backwards, > would reconstruct a series of "frames" all at once and cache them, so > this is a non-issue. For some other simulator not yet available, > perhaps it's not. - Not to be too redundant, but just to try to emphasis the one point which I do feel is important; which is that it's likely important for GBD to initially define a set of commands which are most likely easily supported, as it's likely better to have broad multiple target support for a simpler set of capabilities, than very limited target support for a sophisticated set of capabilities in the absents of the former; "undo/reverse" essentially represents this minimal baseline command functionality, all others are substantially more complex to support in the general case. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 1:53 ` Daniel Jacobowitz 2005-05-21 1:56 ` Daniel Jacobowitz @ 2005-05-21 14:13 ` Paul Schlie 2005-05-21 14:23 ` Daniel Jacobowitz 1 sibling, 1 reply; 80+ messages in thread From: Paul Schlie @ 2005-05-21 14:13 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Dan Shearer, gdb > From: Daniel Jacobowitz <drow@false.org> > On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote: >> - Supporting HW co-simulation is certainly interesting, but fundamentally >> no different; it only extends the definition of "state" typically by >> literally exposing some of the logical CPU/I/O/Peripheral/outside-world >> state in various levels of details depending on the goals of the model, >> and/or simulation itself. (but would guess likely beyond the near term >> goals of attempting to enable GDB support for basic reversible execution?) > > Why should it be? This is another reason that I consider the simulator > a perfectly reasonable place to have the logic. - The predominant downside of such a presumption, is that then NxM targets would need to add support to broadly enable the capability, rather than broadly enabling within GDB, while allowing a target to improve it. > Frank has contributed that sid would more readily support the sort of > snapshot-based reconstruction that you're talking about (thanks Frank). > I think that allowing the target to provide infrun with a view in which > "single step backwards" is possible and then implementing that under > the covers in the target stack would still be the way to go. - Possibly the only reasonable way to do, as the ability to "single step backwards" to a state with the simulation environment may have never previously terminated at is substantially more difficult to support efficiently than simply reverting to a previously reached stable state. > - but I don't think that's a legitimate objection to supporting a smart > simulator which does it internally. - I only object (or observe alternatives) to defining a set of commands which are presently apparently unique to a particular commercial tool's abilities, and which if presumed to form the basis of the requirements for reversible simulation could become an impediment for GDB to support simpler more easily implemented facilities. Conversely, if it were initially presumed that the initial basis for reversible simulation were based on the support of a recursive "undo/reverse" command, then it would be much easier for a broader number of targets (and even potentially GDB itself) to support. > When someone implements reversible debugging in a free simulator and > wants to integrate that with GDB, they'll have the choice of doing the > remaining steps in their simulator or in GDB. - Although our views may differ, I accept and support the simple reality that those to invest the time and resources in a development, have the greatest say in the decisions. (In this case if the desire is to define an interface for a single lone proprietary tool, likely in satisfaction or natural result of a commercial commercial contract to do so, then let it be; but attempting to justify it as a good thing is a bit of a stretch). >> [And suspect you'll find that most HW savvy simulation environments have >> very limited if any support for "reversible" simulation, beyond >> checkpoint-restart. As on a cycle by cycle basis, tracking and recording >> incremental state changes would typically cripple the simulation, and >> potentially even exhaust disk storage for complex models, but limited >> forms do exist, and are useful.] > > You might want to read the papers on the specific simulator we're > discussing using as a starting point; you can find the white paper on > Virtutech's web site. Under the covers, of course, it's probably > checkpoint based. But it's efficient, automatic checkpointing such > that it can provide a reversible view over useful periods of time. > Complete with "HW savvy" details. - Thank you. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 14:13 ` Paul Schlie @ 2005-05-21 14:23 ` Daniel Jacobowitz 2005-05-21 15:04 ` Paul Schlie 0 siblings, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-21 14:23 UTC (permalink / raw) To: Paul Schlie; +Cc: gdb On Sat, May 21, 2005 at 10:13:04AM -0400, Paul Schlie wrote: > > When someone implements reversible debugging in a free simulator and > > wants to integrate that with GDB, they'll have the choice of doing the > > remaining steps in their simulator or in GDB. > > - Although our views may differ, I accept and support the simple reality > that those to invest the time and resources in a development, have the > greatest say in the decisions. (In this case if the desire is to define > an interface for a single lone proprietary tool, likely in satisfaction or > natural result of a commercial commercial contract to do so, then let it > be; but attempting to justify it as a good thing is a bit of a stretch). Paul, I have said repeatedly in this discussion that I think this is a natural, valid, good interface to the functionality. That's my considered opinion; I am not trying to justify anything by it. Please take a deep breath and stop tossing accusation around if you want to be taken seriously. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 14:23 ` Daniel Jacobowitz @ 2005-05-21 15:04 ` Paul Schlie 0 siblings, 0 replies; 80+ messages in thread From: Paul Schlie @ 2005-05-21 15:04 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > From: Daniel Jacobowitz <drow@false.org> >> On Sat, May 21, 2005 at 10:13:04AM -0400, Paul Schlie wrote: >>> When someone implements reversible debugging in a free simulator and >>> wants to integrate that with GDB, they'll have the choice of doing the >>> remaining steps in their simulator or in GDB. >> >> - Although our views may differ, I accept and support the simple reality >> that those to invest the time and resources in a development, have the >> greatest say in the decisions. (In this case if the desire is to define >> an interface for a single lone proprietary tool, likely in satisfaction or >> natural result of a commercial commercial contract to do so, then let it >> be; but attempting to justify it as a good thing is a bit of a stretch). > > Paul, I have said repeatedly in this discussion that I think this is a > natural, valid, good interface to the functionality. That's my > considered opinion; I am not trying to justify anything by it. > > Please take a deep breath and stop tossing accusation around if you > want to be taken seriously. - Agreed, sorry. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 15:49 Paul Schlie 2005-05-20 17:41 ` Dan Shearer @ 2005-05-20 20:58 ` Michael Snyder 2005-05-20 21:35 ` Paul Schlie 1 sibling, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-20 20:58 UTC (permalink / raw) To: Paul Schlie; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb Paul Schlie wrote: > Alternatively to attempting to specify an interface to a lone commercial > reversible simulator, I don't think that's what we're doing -- these commands are meant to be generically useful, as soon as anyone else can support backwards execution. > or presume the intelligence need be "remote" to GDB; We're not doing that either -- the user interface makes no assumption about the target interface. > I wonder if it may be more sensible to consider initially defining the basic > generic facilities by which GDB may directly support undoable/reversible > execution, and checkpoint features. Well, that's an idea that some of us (me, at least...) have thought about too -- but it's, if not orthogonal, at least separable from this discussion. If gdb asks the target to step backwards or continue backwards, we really don't care how the target accomplishes this (eg. whether by restoring a saved state, or actually reversing the execution of individual instructions). I've thought all along that the "bookmark" idea is separable from the "run backwards" idea. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 20:58 ` Michael Snyder @ 2005-05-20 21:35 ` Paul Schlie 0 siblings, 0 replies; 80+ messages in thread From: Paul Schlie @ 2005-05-20 21:35 UTC (permalink / raw) To: Michael Snyder; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb > From: Michael Snyder <msnyder@redhat.com> >> Paul Schlie wrote: >> Alternatively to attempting to specify an interface to a lone commercial >> reversible simulator, > > I don't think that's what we're doing -- these commands are meant > to be generically useful, as soon as anyone else can support > backwards execution. - Sorry for the misinterpretation; but as noted, it seems generally more useful to simply add the capability to GDB, thereby little if any functionality need be dependant on the target simulator, and further by doing so may actually support both check-pointing and undo/reverse execution, on all existing targets, regardless of whether or not they are simulated, or physical targets. >> or presume the intelligence need be "remote" to GDB; > > We're not doing that either -- the user interface makes no > assumption about the target interface. - Then there seems no need to define a reverse-xxxx set of commands at the GDB/target-stub boundary (unless I misunderstand the purposed of the earlier threads of dialog)? >> I wonder if it may be more sensible to consider initially defining the basic >> generic facilities by which GDB may directly support undoable/reversible >> execution, and checkpoint features. > > Well, that's an idea that some of us (me, at least...) have thought about > too -- but it's, if not orthogonal, at least separable from this discussion. > If gdb asks the target to step backwards or continue backwards, we really > don't care how the target accomplishes this - Sounds like you are presuming the "intelligence" to be remote and distinct from GDB, which I believe is fundamentally a less than an ideal premise. > (eg. whether by restoring a saved state, or actually reversing the execution > of individual instructions). - It should be clearly understood that it's factually impossible to define reciprocal semantics for all instructions; therefore the fundamental basis of any undo/reverse execution facility has to be based on the ability to capture state to revert the "effects" of the execution, not "execute" logically reciprocal instructions. (If this is not understood, then its likely premature to attempt to define any interface to support the capability.) > I've thought all along that the "bookmark" idea is separable from the > "run backwards" idea. - There're essentially identical, with the exception that one captures and provides a vehicle to backup to a previously named/designated (bookmarked) state, the other enables the same but to typically to a previously relative state. (single-step reverse execution in it's most general implementation is nothing more than reversing to a previously sequentially captured instruction by instruction check point diff) By recognizing this, there's no need to rely on any information beyond that which GDB already has access to to implement (although may be improved by by simulators which can capture memory state change diffs more efficiently than by brute force) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution
@ 2005-05-16 17:47 Dan Shearer
2005-05-16 18:04 ` Dan Shearer
2005-05-20 18:15 ` Daniel Jacobowitz
0 siblings, 2 replies; 80+ messages in thread
From: Dan Shearer @ 2005-05-16 17:47 UTC (permalink / raw)
To: gdb
On Thu, 12 May 2005 16:08 Michael Snyder wrote at
http://sources.redhat.com/ml/gdb/2005-05/msg00145.html
> I'd like to start adding some commands to gdb to support targets
> that can perform reverse execution (eg. stepping backwards).
> This concept has been around for a number of years now, and I
> have access to a target (the Simics simulator from Virtutech)
> that does it quite handily.
I'm from Virtutech and I'd just like to put some context around this to
make the case that a reversible gdb is a very powerful tool, not just a
curiosity and certainly not specific to one company's simulator.
Reversibility takes some getting used to, so please bear with me for a
long-ish message.
Virtutech's Simics is a simulator, it does go backwards, and every
hacker who's seen it gets as excited as Michael. Simics has a debugger,
but it isn't as capable as gdb (by design) and Virtutech wants to
encourage the existance of a gdb that does reversibility. Simics
already has a gdb stub. So that's why Virtutech is here on this list.
Personally I think reversibility is the biggest advance in debugging
since source code debugging. We've got massive and complicated codebases
we're working with today and we need better productivity. Projects like
KDE, Samba and OpenOffice use valgrind+gdb. With reversibility
productivity will improve even more, I can't make valgrind reversible
but I can help with gdb. That's why I'm here in a personal capacity.
When Reversibility Becomes Useful
---------------------------------
From what I've learned with Simics, reversibility becomes a generally
useful technique when both the simulator and the problem have certain
characteristics.
The simulator needs to be able to save state universally on a networked
world of disparate computers and other electronic devices. If a whole
universe can't be run backwards including diagnostic tools running
inside the universe then reversibility loses a lot of its benefit. The
simulator must also be fast enough to debug problems in real time:
booting an OS must be reasonably quick, for example. And running
backwards must not be slow either, or debugging becomes frustrating
One benefit to the party trick of unbooting a binary-only OS is to see
whether it unboots nearly as quickly as it boots. If it does, chances as
this is reversible hardware that will improve your debugging a lot.
Reversibility helps debugging when the problem:
1. depends on rare circumstances related to a complicated network
environment, and/or
2. involves multiple large, unrelated codebases where the aggregate
behaviour is unpredictable, and/or
3. timing considerations are vital and the inputs are non-deterministic
Reversible Hardware Options
---------------------------
Right now the only fast and complete reversible hardware solution is
Simics, however there is a lot of work happening in the field.
More than a year ago CoVirt project (http://www.eecs.umich.edu/CoVirt/ )
implemented a logging/playback facility for User Mode Linux and modified
gdb to use this to provide reversible execution and debugging. The
project website has a paper titled "Debugging operating systems with
time-traveling virtual machines" that illustrates the point very well.
Around 1999 Cygnus' GPL SID simulator could execute backwards.
Development on reversibility didn't continue so I'm told because it was
seen as "party tricks". Besides SID had flexible hardware watchpoints
like "stop the CPU when an ethernet interrupt is fired" which reduced
the need to search for a particular point in execution for SID's
intended users.
There have been discussions around most of the free simulators talking
about how reversibility could be implemented. I'd guess QEMU is a likely
candidate from the interests of some of the contributors. Valgrind is
another obvious possibility.
The commercial Green Hills Time Machine system instruments real hardware
and then provides an interface for debugging it via Green Hills'
debugger that steps anywhere in the execution history of the hardware.
This might be like Michael Snyder's Tracepoints facility in gdb taken to
an extreme (I haven't used either.)
According to the prior art research done for the Simics Hindsight
whitepaper at http://virtutech.com, reversible hardware has been seen as
doable for over 30 years. Part of the problem has been in implementing
it in a very fast and general way, and the other part has been in
working out why it is so useful.
Current Availability
--------------------
Nobody outside Virtutech has access to Simics reversibility. Simics
Hindsight is due to go into (non-public) beta fairly soon. As part of
this, Virtutech has modified the Simics gdb stub so it can talk to a gdb
that supports reversibility, but this is also in-house for now. So while
Virtutech wants to have a discussion about making its closed-source
simulator available to the kinds of people who live on this list, nobody
has it yet.
Hopefully that explains what reversibility is, why it is important, and
why it is a very significant capability.
--
Dan Shearer
dan@shearer.org
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-16 17:47 Dan Shearer @ 2005-05-16 18:04 ` Dan Shearer 2005-05-20 18:15 ` Daniel Jacobowitz 1 sibling, 0 replies; 80+ messages in thread From: Dan Shearer @ 2005-05-16 18:04 UTC (permalink / raw) To: gdb On Tue, May 17, 2005 at 03:16:49AM +0930, Dan Shearer wrote: > Personally I think reversibility is the biggest advance in debugging > since source code debugging. We've got massive and complicated codebases > we're working with today and we need better productivity. Projects like > KDE, Samba and OpenOffice use valgrind+gdb. With reversibility > productivity will improve even more, I can't make valgrind reversible > but I can help with gdb. That's why I'm here in a personal capacity. > > When Reversibility Becomes Useful > --------------------------------- > > From what I've learned with Simics, reversibility becomes a generally > useful technique when both the simulator and the problem have certain > characteristics. ... going on to describe something that valgrind is unlikely ever to become :-) What I am trying to say, I suppose, is that I have learned from a very general solution how debugging is helped by reversibility. I'm sure some of this knowledge scales down to the vertical solutions, however as per the example of Cygnus' SID simulator if you start looking at a micro-level view it is possible to come to the conclusion "so why bother?" -- Dan Shearer dan@shearer.org ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-16 17:47 Dan Shearer 2005-05-16 18:04 ` Dan Shearer @ 2005-05-20 18:15 ` Daniel Jacobowitz 2005-05-21 0:05 ` Frank Ch. Eigler 1 sibling, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 18:15 UTC (permalink / raw) To: Dan Shearer; +Cc: gdb On Tue, May 17, 2005 at 03:16:49AM +0930, Dan Shearer wrote: > Around 1999 Cygnus' GPL SID simulator could execute backwards. > Development on reversibility didn't continue so I'm told because it was > seen as "party tricks". Besides SID had flexible hardware watchpoints > like "stop the CPU when an ethernet interrupt is fired" which reduced > the need to search for a particular point in execution for SID's > intended users. Does anyone else know the history of this - was any of this code in the version of sid in the src repository? Is any of it still there? -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 18:15 ` Daniel Jacobowitz @ 2005-05-21 0:05 ` Frank Ch. Eigler 2005-05-21 10:13 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Frank Ch. Eigler @ 2005-05-21 0:05 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Dan Shearer, gdb Daniel Jacobowitz <drow@false.org> writes: > On Tue, May 17, 2005 at 03:16:49AM +0930, Dan Shearer wrote: > > Around 1999 Cygnus' GPL SID simulator could execute backwards. > > Development on reversibility didn't continue so I'm told because it was > > seen as "party tricks". [...] > > Does anyone else know the history of this - was any of this code in the > version of sid in the src repository? Is any of it still there? [...] sid provides the same sort of state save/restore facility that any moderately sophisticated but not brilliant target would be able to, like ordinary simulators and even UNIX kernels with process checkpoint support. sid does not perform single-stepping backward as a primitive, since that is very complex in the general case (thus requiring a "brilliant" particular proprietary simulator). The point of the other simulation gentleman on this thread is that by using state snapshots as the basic target-side primitive, one can implement backward stepping on the gdb side in a way that will work even with non-brilliant targets. (By the way, this does not require actual bulk transmission of the state snapshots to gdb, just some sort of management protocol.) - FChE ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 0:05 ` Frank Ch. Eigler @ 2005-05-21 10:13 ` Eli Zaretskii 2005-05-21 10:28 ` Russell Shaw 2005-05-21 14:19 ` Daniel Jacobowitz 0 siblings, 2 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-21 10:13 UTC (permalink / raw) To: fche; +Cc: drow, dan, gdb > Cc: Dan Shearer <dan@shearer.org>, gdb@sources.redhat.com > From: fche@redhat.com (Frank Ch. Eigler) > Date: 20 May 2005 20:05:13 -0400 > > The point of the other simulation gentleman on this thread is that by > using state snapshots as the basic target-side primitive, one can > implement backward stepping on the gdb side in a way that will work > even with non-brilliant targets. (By the way, this does not require > actual bulk transmission of the state snapshots to gdb, just some sort > of management protocol.) This leads me to another idea. Perhaps we should implement a checkpointing infrastructure in GDB, and allow the user (perhaps not by default, but as part of some mode) to go back to every place where the program stopped, for whatever reason: breakpoint, watchpoint, single-stepping, etc. That is, each time the inferior stops, ask the target for the information that fully describes its state, store that state description, and allow the user to rewind the target to any of the stored states. I think this would be a great feature to have in all kinds of targets, including native, since the user can then step forward from the checkpoint to reach any point in between. Think how many times you've did a "next" over a function call, just to find out that the bug is inside the function which you just overstepped, or did a "continue" just to find out at the next breakpoint that the problem you are tracing happened in between this and the previous stop location. An ability to rewind back to the previous stop is something to kill for in such situations. (Btw, I vaguely remember that Turbo Debugger of yore had something like that. Hmmm... I should try to dig out my old copy of that and see if I'm right.) If we implement something like that, perhaps we could ditch all the reverse-* commands whose names we are discussing at such length in this thread, and instead implement only one command, called, say, "rewind" or "backup" or some such. That, and a set/show mode command to enable checkpointing would be enough, I think, to have 99% of the functionality originally suggested in this thread. How would this suggestion of mine map to the remote targets and simulators that support checkpointing on the target side? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 10:13 ` Eli Zaretskii @ 2005-05-21 10:28 ` Russell Shaw 2005-05-21 12:38 ` Eli Zaretskii 2005-05-21 14:19 ` Daniel Jacobowitz 1 sibling, 1 reply; 80+ messages in thread From: Russell Shaw @ 2005-05-21 10:28 UTC (permalink / raw) Cc: gdb Eli Zaretskii wrote: >>Cc: Dan Shearer <dan@shearer.org>, gdb@sources.redhat.com >>From: fche@redhat.com (Frank Ch. Eigler) >>Date: 20 May 2005 20:05:13 -0400 >> >>The point of the other simulation gentleman on this thread is that by >>using state snapshots as the basic target-side primitive, one can >>implement backward stepping on the gdb side in a way that will work >>even with non-brilliant targets. (By the way, this does not require >>actual bulk transmission of the state snapshots to gdb, just some sort >>of management protocol.) > > > This leads me to another idea. Perhaps we should implement a > checkpointing infrastructure in GDB, and allow the user (perhaps not > by default, but as part of some mode) to go back to every place where > the program stopped, for whatever reason: breakpoint, watchpoint, > single-stepping, etc. That is, each time the inferior stops, ask the > target for the information that fully describes its state, store that > state description, and allow the user to rewind the target to any of > the stored states. > > I think this would be a great feature to have in all kinds of targets, > including native, since the user can then step forward from the > checkpoint to reach any point in between. > > Think how many times you've did a "next" over a function call, just to > find out that the bug is inside the function which you just > overstepped, or did a "continue" just to find out at the next > breakpoint that the problem you are tracing happened in between this > and the previous stop location. An ability to rewind back to the > previous stop is something to kill for in such situations. > > (Btw, I vaguely remember that Turbo Debugger of yore had something > like that. Hmmm... I should try to dig out my old copy of that and > see if I'm right.) > > If we implement something like that, perhaps we could ditch all the > reverse-* commands whose names we are discussing at such length in > this thread, and instead implement only one command, called, say, > "rewind" or "backup" or some such. That, and a set/show mode command > to enable checkpointing would be enough, I think, to have 99% of the > functionality originally suggested in this thread. > > How would this suggestion of mine map to the remote targets and > simulators that support checkpointing on the target side? It'd be better to store the state of every step in to a circular buffer of size 1000 (the user could change that size with a command). Then you could just: "back 10" to go to the point that would have been 10 steps ago, or "back 3 myfunc" to go back to the third last call of myfunc(). That way, there's only one backwards command to remember, and maybe a command to change the history buffer size. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 10:28 ` Russell Shaw @ 2005-05-21 12:38 ` Eli Zaretskii 2005-05-21 12:55 ` Russell Shaw 2005-05-21 14:39 ` Russell Shaw 0 siblings, 2 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-21 12:38 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb > Date: Sat, 21 May 2005 20:30:16 +1000 > From: Russell Shaw <rjshaw@netspace.net.au> > Cc: gdb@sources.redhat.com > > It'd be better to store the state of every step in to a circular buffer > of size 1000 (the user could change that size with a command). When you say ``it'd be better'', what is the alternative that you think is worse than your suggestion? What I wrote didn't say how many previous states to remember, nor what data structure to use for that. Also, I hope you don't mean ``every step'', but rather ``every stop''. What I suggested didn't involve single-stepping the program, so GDB can only collect the target state when the target stops, not after each instruction. > That way, there's only one backwards command to remember, and maybe a > command to change the history buffer size. That's essentially what I suggested: to have a single command to go back to one of the places where we have enough information to restore the target state. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 12:38 ` Eli Zaretskii @ 2005-05-21 12:55 ` Russell Shaw 2005-05-21 14:39 ` Russell Shaw 1 sibling, 0 replies; 80+ messages in thread From: Russell Shaw @ 2005-05-21 12:55 UTC (permalink / raw) Cc: gdb Eli Zaretskii wrote: >>Date: Sat, 21 May 2005 20:30:16 +1000 >>From: Russell Shaw <rjshaw@netspace.net.au> >>Cc: gdb@sources.redhat.com >> >>It'd be better to store the state of every step in to a circular buffer >>of size 1000 (the user could change that size with a command). > > When you say ``it'd be better'', what is the alternative that you > think is worse than your suggestion? What I wrote didn't say how many > previous states to remember, nor what data structure to use for that. > > Also, I hope you don't mean ``every step'', but rather ``every stop''. > What I suggested didn't involve single-stepping the program, so GDB > can only collect the target state when the target stops, not after > each instruction. Yes, that's what i meant (every step). It could be configureable so that the policy can be set to every user-stop, every function call, or disabled alltogether. The idea is that you could run from main() until a segfault happens, then "back 10" and step thru the last few actions. >>That way, there's only one backwards command to remember, and maybe a >>command to change the history buffer size. > > That's essentially what I suggested: to have a single command to go > back to one of the places where we have enough information to restore > the target state. I was hoping to have target state for all of the last 100 or 1000 steps. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 12:38 ` Eli Zaretskii 2005-05-21 12:55 ` Russell Shaw @ 2005-05-21 14:39 ` Russell Shaw 1 sibling, 0 replies; 80+ messages in thread From: Russell Shaw @ 2005-05-21 14:39 UTC (permalink / raw) Cc: gdb Eli Zaretskii wrote: >>Date: Sat, 21 May 2005 20:30:16 +1000 >>From: Russell Shaw <rjshaw@netspace.net.au> >>Cc: gdb@sources.redhat.com >> >>It'd be better to store the state of every step in to a circular buffer >>of size 1000 (the user could change that size with a command). > > When you say ``it'd be better'', what is the alternative that you > think is worse than your suggestion? What I wrote didn't say how many > previous states to remember, nor what data structure to use for that. > > Also, I hope you don't mean ``every step'', but rather ``every stop''. > What I suggested didn't involve single-stepping the program, so GDB > can only collect the target state when the target stops, not after > each instruction. Yes, that's what i meant (every step). It could be configureable so that the policy can be set to every user-stop, every function call, or disabled alltogether. The idea is that you could run from main() until a segfault happens, then "back 10" and step thru the last few actions. >>That way, there's only one backwards command to remember, and maybe a >>command to change the history buffer size. > > That's essentially what I suggested: to have a single command to go > back to one of the places where we have enough information to restore > the target state. I was hoping to have target state for all of the last 100 or 1000 steps. There could be two things the user chooses: When you go back to a previous point then start stepping, all you see is a replay of what happened, rather than any real interactive or live executions happening. When you step past the current context, then 'real' simulation is again happening as usual, or When you go back to a previous point then start stepping, then 'real' simulation is again happening as usual. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 10:13 ` Eli Zaretskii 2005-05-21 10:28 ` Russell Shaw @ 2005-05-21 14:19 ` Daniel Jacobowitz 2005-05-21 15:46 ` Eli Zaretskii 1 sibling, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-21 14:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: fche, dan, gdb On Sat, May 21, 2005 at 01:07:41PM +0300, Eli Zaretskii wrote: > This leads me to another idea. Perhaps we should implement a > checkpointing infrastructure in GDB, and allow the user (perhaps not > by default, but as part of some mode) to go back to every place where > the program stopped, for whatever reason: breakpoint, watchpoint, > single-stepping, etc. That is, each time the inferior stops, ask the > target for the information that fully describes its state, store that > state description, and allow the user to rewind the target to any of > the stored states. > > I think this would be a great feature to have in all kinds of targets, > including native, since the user can then step forward from the > checkpoint to reach any point in between. Two things. One, it requires extensive additional support from the target. State is huge and complicated - multiple threads, file system operations, network packets. You need a target that supports checkpointing to do this. I'm told there are native platforms which could offer this - I just don't know what any of them are. Two, this is basically the same thing as the bookmarking feature already proposed in this thread; just have GDB automatically take a bookmark at every stop. > If we implement something like that, perhaps we could ditch all the > reverse-* commands whose names we are discussing at such length in > this thread, and instead implement only one command, called, say, > "rewind" or "backup" or some such. That, and a set/show mode command > to enable checkpointing would be enough, I think, to have 99% of the > functionality originally suggested in this thread. Not at all. Here's a big use of reversible debugging: timing-sensitive or otherwise very hard-to-reproduce problems. You want to be able to leave the program running, hooked up to a simulator and a debugger, and then once the mysterious bug has occurred back up a little bit to see why. And the only way that checkpointing could be as user-friendly as stepping would be if GDB emulated the latter on the former, I think (already suggested). > How would this suggestion of mine map to the remote targets and > simulators that support checkpointing on the target side? Just fine, all it needs is bookmarking. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 14:19 ` Daniel Jacobowitz @ 2005-05-21 15:46 ` Eli Zaretskii 2005-05-21 17:43 ` Daniel Jacobowitz 0 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-21 15:46 UTC (permalink / raw) To: fche, dan, gdb > Date: Sat, 21 May 2005 10:19:31 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com > > One, it requires extensive additional support from the target. State > is huge and complicated - multiple threads, file system operations, > network packets. You need a target that supports checkpointing to do > this. I'm told there are native platforms which could offer this - I > just don't know what any of them are. Well, at least the Linux kernel developers could perhaps be persuaded to add such a support. > Two, this is basically the same thing as the bookmarking feature > already proposed in this thread; just have GDB automatically take a > bookmark at every stop. Correct. What I'm saying is that by adding this we would provide a large part of user-level functionality that is served by the full set of reverse-* commands, but with the advantages that: (a) the list of new commands is much smaller and thus simpler (b) we don't need to figure out the right semantics of tricky commands like "reverse-next" and "reverse-finish" (c) part of the implementation is on the GDB side (as opoosed to the target side), so it will be easier to enable it for more targets > > If we implement something like that, perhaps we could ditch all the > > reverse-* commands whose names we are discussing at such length in > > this thread, and instead implement only one command, called, say, > > "rewind" or "backup" or some such. That, and a set/show mode command > > to enable checkpointing would be enough, I think, to have 99% of the > > functionality originally suggested in this thread. > > Not at all. Here's a big use of reversible debugging: timing-sensitive > or otherwise very hard-to-reproduce problems. You want to be able to > leave the program running, hooked up to a simulator and a debugger, and > then once the mysterious bug has occurred back up a little bit to see > why. Okay so perhaps it's less than 99%, but it's still a large portion. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 15:46 ` Eli Zaretskii @ 2005-05-21 17:43 ` Daniel Jacobowitz 2005-05-23 19:39 ` Dan Shearer 0 siblings, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-21 17:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: fche, dan, gdb On Sat, May 21, 2005 at 06:40:45PM +0300, Eli Zaretskii wrote: > > Date: Sat, 21 May 2005 10:19:31 -0400 > > From: Daniel Jacobowitz <drow@false.org> > > Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com > > > > One, it requires extensive additional support from the target. State > > is huge and complicated - multiple threads, file system operations, > > network packets. You need a target that supports checkpointing to do > > this. I'm told there are native platforms which could offer this - I > > just don't know what any of them are. > > Well, at least the Linux kernel developers could perhaps be persuaded > to add such a support. Maybe. It would be a major piece of surgery; I think that checkpointing has been implemented before, but never merged. > > Two, this is basically the same thing as the bookmarking feature > > already proposed in this thread; just have GDB automatically take a > > bookmark at every stop. > > Correct. What I'm saying is that by adding this we would provide a > large part of user-level functionality that is served by the full set > of reverse-* commands, but with the advantages that: > > (a) the list of new commands is much smaller and thus simpler > (b) we don't need to figure out the right semantics of tricky > commands like "reverse-next" and "reverse-finish" But the new commands would be much less useful. To me, at least. Why should we choose a lesser solution just to avoid figuring out the complicated bits of a more thorough solution? > (c) part of the implementation is on the GDB side (as opoosed to the > target side), so it will be easier to enable it for more targets (c) is Paul's and Frank's point. I think that it should wait until there's a target that doesn't provide it on the target side; I don't see a problem in using it if it's available. > > Not at all. Here's a big use of reversible debugging: timing-sensitive > > or otherwise very hard-to-reproduce problems. You want to be able to > > leave the program running, hooked up to a simulator and a debugger, and > > then once the mysterious bug has occurred back up a little bit to see > > why. > > Okay so perhaps it's less than 99%, but it's still a large portion. Well I can't (yet!) speak from experience, but I think that you're leaving out the most useful bits. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-21 17:43 ` Daniel Jacobowitz @ 2005-05-23 19:39 ` Dan Shearer 0 siblings, 0 replies; 80+ messages in thread From: Dan Shearer @ 2005-05-23 19:39 UTC (permalink / raw) To: Eli Zaretskii, fche, gdb On Sat, May 21, 2005 at 01:43:32PM -0400, Daniel Jacobowitz wrote: > On Sat, May 21, 2005 at 06:40:45PM +0300, Eli Zaretskii wrote: > > > Date: Sat, 21 May 2005 10:19:31 -0400 > > > From: Daniel Jacobowitz <drow@false.org> > > > Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com > > > > > > One, it requires extensive additional support from the target. State > > > is huge and complicated - multiple threads, file system operations, > > > network packets. You need a target that supports checkpointing to do > > > this. I'm told there are native platforms which could offer this - I > > > just don't know what any of them are. > > > > Well, at least the Linux kernel developers could perhaps be persuaded > > to add such a support. > > Maybe. It would be a major piece of surgery; I think that > checkpointing has been implemented before, but never merged. You can get a feeling for how much work there is by looking at the subset addressed in software suspend http://www.suspend2.net . And this is just for part of one architecture on one operating system. Generic checkpointing in Linux on all platforms would be wonderful to have but I hardly think gdb reversibility will be a driving motivation. And even if it existed: a) what about the heisenbugs? A checkpointable OS still isn't a disinterested party to a debugging session b) what about all the other OSs? Maybe one day we'll get there, but in the meantime the only realistic solution I know of is to do simulation in a userspace process, because then checkpointing becomes a solvable problem. Not always an easy problem because of issues with things like SMP and cranky peripherals but it is at least possible to have the checkpointing mechanism out of the scope of the OS being checkpointed/debugged. -- Dan Shearer dan@shearer.org ^ permalink raw reply [flat|nested] 80+ messages in thread
* [discuss] Support for reverse-execution @ 2005-05-12 23:08 Michael Snyder 2005-05-13 6:23 ` Eli Zaretskii 2005-05-20 15:05 ` Vladimir Prus 0 siblings, 2 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-12 23:08 UTC (permalink / raw) To: gdb I'd like to start adding some commands to gdb to support targets that can perform reverse execution (eg. stepping backwards). This concept has been around for a number of years now, and I have access to a target (the Simics simulator from Virtutech) that does it quite handily. I propose we add something like the following commands (names open to discussion): reverse-continue -- start executing backwards until something interesting happens (most likely hitting a breakpoint). reverse-stepi -- "un-execute" the previous instruction. reverse-step -- "un-execute" the previous source line. reverse-finish or "un-call" -- proceed backward until the current function is about to be called by its caller. reverse-until... etc. Along with these commands, we would need at least two new remote-protocol messages: "rc" for reverse-continue, and "rs" for reverse-stepi. I think all of the above user commands could be implemented on these primatives. Obviously if the remote target doesn't understand these primatives, the user command would error. Finally, we'd need a new entry for the target vector -- something like "to_resume_backwards". If the target vector doesn't export this method, the user command would error. At least one target (the Simics simulator) would support these commands immediately, and once they exist, their presence may encourage other targets to implement reverse execution. We know that the technology exists, it just needs a user interface to be useful. Comments? Michael Snyder Red Hat ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-12 23:08 Michael Snyder @ 2005-05-13 6:23 ` Eli Zaretskii 2005-05-19 13:46 ` Daniel Jacobowitz 2005-05-20 15:05 ` Vladimir Prus 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-13 6:23 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb > From: "Michael Snyder" <msnyder@redhat.com> > Date: Thu, 12 May 2005 16:08:34 -0700 > > I'd like to start adding some commands to gdb to support targets > that can perform reverse execution (eg. stepping backwards). > This concept has been around for a number of years now, and I > have access to a target (the Simics simulator from Virtutech) > that does it quite handily. Sounds like a great idea. > I propose we add something like the following commands > (names open to discussion): > > reverse-continue -- start executing backwards until something > interesting happens (most likely hitting a breakpoint). > > reverse-stepi -- "un-execute" the previous instruction. > > reverse-step -- "un-execute" the previous source line. > > reverse-finish or "un-call" -- proceed backward until > the current function is about to be called by its caller. > > reverse-until... etc. Not "reverse", "backwards" or "back". "Reverse" will become ambiguous once we have two possible directions. > Along with these commands, we would need at least two new > remote-protocol messages: "rc" for reverse-continue, and "rs" > for reverse-stepi. I think all of the above user commands could > be implemented on these primatives. Obviously if the remote > target doesn't understand these primatives, the user command > would error. > > Finally, we'd need a new entry for the target vector -- > something like "to_resume_backwards". If the target vector > doesn't export this method, the user command would error. Please don't forget the manual changes for these features. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-13 6:23 ` Eli Zaretskii @ 2005-05-19 13:46 ` Daniel Jacobowitz 2005-05-19 18:46 ` Michael Snyder ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-19 13:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Michael Snyder, gdb On Fri, May 13, 2005 at 09:19:17AM +0300, Eli Zaretskii wrote: > > I propose we add something like the following commands > > (names open to discussion): > > > > reverse-continue -- start executing backwards until something > > interesting happens (most likely hitting a breakpoint). > > > > reverse-stepi -- "un-execute" the previous instruction. > > > > reverse-step -- "un-execute" the previous source line. > > > > reverse-finish or "un-call" -- proceed backward until > > the current function is about to be called by its caller. > > > > reverse-until... etc. > > Not "reverse", "backwards" or "back". "Reverse" will become ambiguous > once we have two possible directions. Actually I think "reverse" is a more logical term. Drivers don't seem to get confused when they put a car into reverse, which is a natural parallel. The program doesn't have a persistant direction. If it's stopped, "continue" will always move forwards in time and "reverse-continue" will always move backwards. "back-step" is kind of appealing, but "back-continue" and "back-next" just don't sound right. I suppose we could use "continue-backwards"? I would just have called the command rcontinue, but reverse-continue is fine with me too; either way we'll hopefully offer abbreviations, like "c" and "si". > > Along with these commands, we would need at least two new > > remote-protocol messages: "rc" for reverse-continue, and "rs" > > for reverse-stepi. I think all of the above user commands could > > be implemented on these primatives. Obviously if the remote > > target doesn't understand these primatives, the user command > > would error. You used rc, Johan used bc. It should be consistent with the command names. I wish one of you had noticed vCont though, at least as an example :-) `vCont'[;ACTION[`:'TID]]... -- extended resume Resume the inferior. Different actions may be specified for each thread. If an action is specified with no TID, then it is applied to any threads that don't have a specific action specified; if no default action is specified then other threads should remain stopped. Specifying multiple default actions is an error; specifying no actions is also an error. Thread IDs are specified in hexadecimal. Currently supported actions are: Hmm, thinking about this some more, maybe not such a bright idea. The documentation would need some clarification, since even if we someday have a simulator which both supports reverse execution and presents a view of multiple threads (the implications are dizzying) I'm sure it will be strictly limited in how you can back up the program. Backing up one thread while running another forwards, or even while leaving another stopped, doesn't make sense - it creates a view of execution which never occurred in the previous run. However, there are still two advantages to vCont: consistency, and a pre-existing query packet, vCont?. I'm not dead set on this idea; the benefits of consistency are pretty small in this case and the thread-specific expressive power of vCont is not obviously useful for reverse execution. However I think a query packet is still wise. This allows a front end to modify its interface based on whether the target supports reverse execution without having to try it. > > Finally, we'd need a new entry for the target vector -- > > something like "to_resume_backwards". If the target vector > > doesn't export this method, the user command would error. Whichever name we settle on let's be consistent - if we use "reverse" for the commands and documentation, we should use if for the target hook too. > Please don't forget the manual changes for these features. Definitely! -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 13:46 ` Daniel Jacobowitz @ 2005-05-19 18:46 ` Michael Snyder 2005-05-19 19:26 ` Johan Rydberg 2005-05-20 10:55 ` Eli Zaretskii 2005-05-20 20:38 ` Michael Snyder 2 siblings, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-19 18:46 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Eli Zaretskii, gdb Daniel Jacobowitz wrote: > On Fri, May 13, 2005 at 09:19:17AM +0300, Eli Zaretskii wrote: > >>>I propose we add something like the following commands >>>(names open to discussion): >>> >>>reverse-continue -- start executing backwards until something >>>interesting happens (most likely hitting a breakpoint). >>> >>>reverse-stepi -- "un-execute" the previous instruction. >>> >>>reverse-step -- "un-execute" the previous source line. >>> >>>reverse-finish or "un-call" -- proceed backward until >>>the current function is about to be called by its caller. >>> >>>reverse-until... etc. >> >>Not "reverse", "backwards" or "back". "Reverse" will become ambiguous >>once we have two possible directions. > > > Actually I think "reverse" is a more logical term. Drivers don't > seem to get confused when they put a car into reverse, which is a > natural parallel. The program doesn't have a persistant direction. > If it's stopped, "continue" will always move forwards in time > and "reverse-continue" will always move backwards. > > "back-step" is kind of appealing, but "back-continue" and "back-next" > just don't sound right. I suppose we could use "continue-backwards"? > > I would just have called the command rcontinue, but reverse-continue is > fine with me too; either way we'll hopefully offer abbreviations, like > "c" and "si". Yeah, I was thinking of "reverse-continue" as the long-form, and anticipating one or more abbreviated aliases such as rcontinue or rc. >>>Along with these commands, we would need at least two new >>>remote-protocol messages: "rc" for reverse-continue, and "rs" >>>for reverse-stepi. I think all of the above user commands could >>>be implemented on these primatives. Obviously if the remote >>>target doesn't understand these primatives, the user command >>>would error. > > > You used rc, Johan used bc. It should be consistent with the command > names. Johan? Is there a conversation that I missed? > I wish one of you had noticed vCont though, at least as an > example :-) Thanks for bringing it to my (our) attention. > [threads] Yeah, as I currently think of it, reverse execution would deterministically reiterate (or de-iterate) what happened before -- therefore you cannot expect to change the course of the execution while running in reverse. Any interferance with thread scheduling would change the outcome (income?) If you first back up, and then shift into forward again, that's another story... > I'm not dead set on this idea; the benefits of consistency are pretty > small in this case and the thread-specific expressive power of vCont is > not obviously useful for reverse execution. However I think a query > packet is still wise. This allows a front end to modify its interface > based on whether the target supports reverse execution without having > to try it. My thinking was (admittedly old-school): just try it, and if the target doesn't understand it, then report accordingly to the user. But I'm totally open to other suggestions. >>>Finally, we'd need a new entry for the target vector -- >>>something like "to_resume_backwards". If the target vector >>>doesn't export this method, the user command would error. > > > Whichever name we settle on let's be consistent - if we use "reverse" > for the commands and documentation, we should use if for the target > hook too. Sure. >>Please don't forget the manual changes for these features. > > > Definitely! Sure. ;-) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 18:46 ` Michael Snyder @ 2005-05-19 19:26 ` Johan Rydberg 0 siblings, 0 replies; 80+ messages in thread From: Johan Rydberg @ 2005-05-19 19:26 UTC (permalink / raw) To: Michael Snyder; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb Michael Snyder wrote: >> You used rc, Johan used bc. It should be consistent with the command >> names. > > Johan? Is there a conversation that I missed? No. I just choose "bc" instead of "rc" because our GDB stub used "r" for 'reset' -- but I can't seem to find that "r" is used in remote.c, so I guess our code is at fault. But as I stated earlier, the patch should been seen as a proof-of-concept. Nothing is written in stone here. ~j ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 13:46 ` Daniel Jacobowitz 2005-05-19 18:46 ` Michael Snyder @ 2005-05-20 10:55 ` Eli Zaretskii 2005-05-20 13:04 ` Daniel Jacobowitz 2005-05-20 20:38 ` Michael Snyder 2 siblings, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 10:55 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb > Date: Thu, 19 May 2005 09:41:50 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com > > > Not "reverse", "backwards" or "back". "Reverse" will become ambiguous > > once we have two possible directions. > > Actually I think "reverse" is a more logical term. Drivers don't > seem to get confused when they put a car into reverse One can learn anything, given enough practice. So the fact drivers can get accustomed to this doesn't mean it won't be harder for GDB users. Most people don't use GDB as frequently as they drive cars. > The program doesn't have a persistant direction. I envision that adding this could be a natural extension. Using "backwards" rather than "reverse" will save us from the ambiguity if we ever add such a feature. > "back-continue" and "back-next" just don't sound right. Neither does "reverse-next". Perhaps we should use "prev" instead. > Whichever name we settle on let's be consistent - if we use "reverse" > for the commands and documentation, we should use if for the target > hook too. Yes. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 10:55 ` Eli Zaretskii @ 2005-05-20 13:04 ` Daniel Jacobowitz 2005-05-20 14:30 ` Eli Zaretskii 2005-05-20 20:48 ` Michael Snyder 0 siblings, 2 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 13:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Michael Snyder, gdb On Fri, May 20, 2005 at 01:51:31PM +0300, Eli Zaretskii wrote: > > Date: Thu, 19 May 2005 09:41:50 -0400 > > From: Daniel Jacobowitz <drow@false.org> > > Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com > > > > > Not "reverse", "backwards" or "back". "Reverse" will become ambiguous > > > once we have two possible directions. > > > > Actually I think "reverse" is a more logical term. Drivers don't > > seem to get confused when they put a car into reverse > > One can learn anything, given enough practice. So the fact drivers > can get accustomed to this doesn't mean it won't be harder for GDB > users. Most people don't use GDB as frequently as they drive cars. But many GDB users drive cars :-) Anyway let's not go there. You think it is ambiguous; I disagree. > > The program doesn't have a persistant direction. > > I envision that adding this could be a natural extension. Using > "backwards" rather than "reverse" will save us from the ambiguity if > we ever add such a feature. I really don't think that we should have such a feature. It seems like a crummy interface - a resume command which goes either forwards or backwards in time depending on some global state? I think that auto-repeat when you hit return at a GDB prompt is all we want to have, and we already have that. > > "back-continue" and "back-next" just don't sound right. > > Neither does "reverse-next". Perhaps we should use "prev" instead. It seems to me that if we give them unique names, the logical parallel with existing commands may be lost. But perhaps not. Let's try for the full set: continue reverse-continue step reverse-step next reverse-next stepi reverse-stepi nexti reverse-nexti until reverse-until advance reverse-advance finish reverse-finish I think that's the full set of reversible commands. Which of them don't work? I agree that reverse-next is a little weak, but everything else seems OK. And we aren't limited to one name for things! We could add "prev" as an alias to "next" if you like that. We could use r-prefixed commands. I don't think that helps much, since we're already planning to offer abbreviations like "rs" and "rni", but they're my second-favorite choice: rcontinue, rstep, rnext, rstepi, rnexti, runtil, radvance, rfinish We could use "backwards" for everything. Those mostly sound right, except that backwards has some unfortunate connotations. I think that advance and finish come out as particularly odd: backwards-continue, backwards-step, backwards-next, backwards-stepi, backwards-nexti, backwards-until, backwards-advance, backwards-finish This one's kind of nice, we could use suffixes instead. But next-backwards is very awkward: continue-backwards, step-backwards, next-backwards, stepi-backwards, nexti-backwards, until-backwards, advance-backwards, finish-backwards -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 13:04 ` Daniel Jacobowitz @ 2005-05-20 14:30 ` Eli Zaretskii 2005-05-20 14:43 ` Andreas Schwab 2005-05-20 20:48 ` Michael Snyder 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 14:30 UTC (permalink / raw) To: gdb > Date: Fri, 20 May 2005 09:03:42 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com > > > > The program doesn't have a persistant direction. > > > > I envision that adding this could be a natural extension. Using > > "backwards" rather than "reverse" will save us from the ambiguity if > > we ever add such a feature. > > I really don't think that we should have such a feature. It seems like > a crummy interface - a resume command which goes either forwards or > backwards in time depending on some global state? I actually don't hate the idea so much, but let's not argue about hypothetical features. > > > "back-continue" and "back-next" just don't sound right. > > > > Neither does "reverse-next". Perhaps we should use "prev" instead. > > It seems to me that if we give them unique names, the logical parallel > with existing commands may be lost. I'd rather lose parallel based on literal similarity, than introduce commands whose names contain an internal contradiction, like back-next or reverse-next. To me, "next" implicitly means "forward", similar to your interpretation of "reverse" to mean "backward". > But perhaps not. Let's try for > the full set: > continue reverse-continue > step reverse-step > next reverse-next > stepi reverse-stepi > nexti reverse-nexti > until reverse-until > advance reverse-advance > finish reverse-finish > > I think that's the full set of reversible commands. Which of them > don't work? I agree that reverse-next is a little weak, but everything > else seems OK. reverse-nexti is like reverse-next, reverse-advance has similar problems, and reverse-finish is also awkward (since we don't ``finish'' anything, we get to the beginning, not the end). > We could use r-prefixed commands. I don't think that helps much, since > we're already planning to offer abbreviations like "rs" and "rni", but > they're my second-favorite choice: > rcontinue, rstep, rnext, rstepi, rnexti, runtil, radvance, rfinish These are better, since the single `r' doesn't produce the kind of contradictions that "reverse" does. > This one's kind of nice, we could use suffixes instead. But > next-backwards is very awkward: > continue-backwards, step-backwards, next-backwards, stepi-backwards, > nexti-backwards, until-backwards, advance-backwards, finish-backwards These are okay from the mnemonic point of view, but they have a big disadvantage for a CLI junky such as myself: they make "next" etc. ambiguous, and you need to type a long string to disambiguate the commands that today have very short unambiguous abbreviations. So it seems that, unless someone else comes up with a better idea, rnext, rstep, etc. is the best compromise. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 14:30 ` Eli Zaretskii @ 2005-05-20 14:43 ` Andreas Schwab 0 siblings, 0 replies; 80+ messages in thread From: Andreas Schwab @ 2005-05-20 14:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb "Eli Zaretskii" <eliz@gnu.org> writes: >> Date: Fri, 20 May 2005 09:03:42 -0400 >> From: Daniel Jacobowitz <drow@false.org> >> Cc: Michael Snyder <msnyder@redhat.com>, gdb@sources.redhat.com >> >> This one's kind of nice, we could use suffixes instead. But >> next-backwards is very awkward: >> continue-backwards, step-backwards, next-backwards, stepi-backwards, >> nexti-backwards, until-backwards, advance-backwards, finish-backwards > > These are okay from the mnemonic point of view, but they have a big > disadvantage for a CLI junky such as myself: they make "next" etc. > ambiguous, They don't have to. We have "s" as alias of "step" even though strictly speaking it is ambigous (we have many commands starting with "s"). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 13:04 ` Daniel Jacobowitz 2005-05-20 14:30 ` Eli Zaretskii @ 2005-05-20 20:48 ` Michael Snyder 2005-05-20 20:51 ` Daniel Jacobowitz 1 sibling, 1 reply; 80+ messages in thread From: Michael Snyder @ 2005-05-20 20:48 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Eli Zaretskii, gdb Daniel Jacobowitz wrote: > It seems to me that if we give them unique names, the logical parallel > with existing commands may be lost. But perhaps not. Let's try for > the full set: > continue reverse-continue > step reverse-step > next reverse-next > stepi reverse-stepi > nexti reverse-nexti > until reverse-until > advance reverse-advance > finish reverse-finish > > I think that's the full set of reversible commands. reverse-return? <shudder> > Which of them > don't work? I agree that reverse-next is a little weak, but everything > else seems OK. And we aren't limited to one name for things! We could > add "prev" as an alias to "next" if you like that. I like these, as being the most informative, with shorter and perhaps more mnemonic versions (such as prev) as aliases. Eli, you should like these because they're somewhat self-documenting (not that we'd want to skimp on the real docs) > We could use r-prefixed commands. I don't think that helps much, since > we're already planning to offer abbreviations like "rs" and "rni", but > they're my second-favorite choice: > rcontinue, rstep, rnext, rstepi, rnexti, runtil, radvance, rfinish > > We could use "backwards" for everything. Those mostly sound right, > except that backwards has some unfortunate connotations. What if, in addition to what you describe above, we defined a *prefix* command "backwards" -- which would simply modify the other commands, eg. "backwards continue" (no hyphen) would call continue with whatever parameters would make it proceed backwards (or would call reverse-continue, or whatever). Maybe this is too many ways to do the same thing, but it would cost us essentially nothing... Furthermore, we could implement as many of these interfaces as we wish, hidden in "maintainer mode" or something, and try them out -- see how we like them. > I think > that advance and finish come out as particularly odd: > backwards-continue, backwards-step, backwards-next, backwards-stepi, > backwards-nexti, backwards-until, backwards-advance, backwards-finish > > This one's kind of nice, we could use suffixes instead. But > next-backwards is very awkward: > continue-backwards, step-backwards, next-backwards, stepi-backwards, > nexti-backwards, until-backwards, advance-backwards, finish-backwards > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 20:48 ` Michael Snyder @ 2005-05-20 20:51 ` Daniel Jacobowitz 0 siblings, 0 replies; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 20:51 UTC (permalink / raw) To: Michael Snyder; +Cc: Eli Zaretskii, gdb On Fri, May 20, 2005 at 01:48:10PM -0700, Michael Snyder wrote: > Daniel Jacobowitz wrote: > > >It seems to me that if we give them unique names, the logical parallel > >with existing commands may be lost. But perhaps not. Let's try for > >the full set: > > continue reverse-continue > > step reverse-step > > next reverse-next > > stepi reverse-stepi > > nexti reverse-nexti > > until reverse-until > > advance reverse-advance > > finish reverse-finish > > > >I think that's the full set of reversible commands. > > reverse-return? <shudder> Thank the lord, we don't have to worry about that one. It isn't possible. Not even kinda. I mean... uh... where would you go? Bookmarks fill a sort of similar role. > What if, in addition to what you describe above, we defined > a *prefix* command "backwards" -- which would simply modify > the other commands, eg. "backwards continue" (no hyphen) > would call continue with whatever parameters would make it > proceed backwards (or would call reverse-continue, or whatever). > > Maybe this is too many ways to do the same thing, but > it would cost us essentially nothing... > > Furthermore, we could implement as many of these interfaces > as we wish, hidden in "maintainer mode" or something, and > try them out -- see how we like them. True. I think that's a little excessive, but at this point there do seem to be three useful sets of names: reverse-continue, rcontinue, and rc. I'd support using all three. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-19 13:46 ` Daniel Jacobowitz 2005-05-19 18:46 ` Michael Snyder 2005-05-20 10:55 ` Eli Zaretskii @ 2005-05-20 20:38 ` Michael Snyder 2 siblings, 0 replies; 80+ messages in thread From: Michael Snyder @ 2005-05-20 20:38 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Eli Zaretskii, gdb Daniel Jacobowitz wrote: > I would just have called the command rcontinue, but reverse-continue is > fine with me too; either way we'll hopefully offer abbreviations, like > "c" and "si". I can't remember if I said this already, but... If you look at gcore.c, you'll see that the actual name of the command is "generate-core-file". Then it's aliased to the shorter "gcore". That's what I had in mind here. A long-but-descriptive form (which perhaps no one will ever type), and one or more short forms such as rcontinue and rc. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-12 23:08 Michael Snyder 2005-05-13 6:23 ` Eli Zaretskii @ 2005-05-20 15:05 ` Vladimir Prus 2005-05-20 15:58 ` Eli Zaretskii 2005-05-20 19:27 ` Stan Shebs 1 sibling, 2 replies; 80+ messages in thread From: Vladimir Prus @ 2005-05-20 15:05 UTC (permalink / raw) To: gdb Michael Snyder wrote: > I'd like to start adding some commands to gdb to support targets > that can perform reverse execution (eg. stepping backwards). > This concept has been around for a number of years now, and I > have access to a target (the Simics simulator from Virtutech) > that does it quite handily. > > I propose we add something like the following commands > (names open to discussion): > > reverse-continue -- start executing backwards until something > interesting happens (most likely hitting a breakpoint). > > reverse-stepi -- "un-execute" the previous instruction. > > reverse-step -- "un-execute" the previous source line. > > reverse-finish or "un-call" -- proceed backward until > the current function is about to be called by its caller. > > reverse-until... etc. Would not it be better to have a single "reverse" command which puts the debugger in "reverse" mode -- making step/stepi/next/nexti go backward. This might be handier for UI -- after all "step" can be abbreviated as 's', but reverse-step can't be abbreviated. This might be better in GUI too -- instead of doubling the number of "step" commands you'd have a single "gear" switch, that can be in either "forward" or "reverse" position. - Volodya ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 15:05 ` Vladimir Prus @ 2005-05-20 15:58 ` Eli Zaretskii 2005-05-20 18:14 ` Daniel Jacobowitz 2005-05-20 19:27 ` Stan Shebs 1 sibling, 1 reply; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 15:58 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > From: Vladimir Prus <ghost@cs.msu.su> > Date: Fri, 20 May 2005 18:45:22 +0400 > > Would not it be better to have a single "reverse" command which puts the > debugger in "reverse" mode -- making step/stepi/next/nexti go backward. Daniel, I rest my case ;-) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 15:58 ` Eli Zaretskii @ 2005-05-20 18:14 ` Daniel Jacobowitz 2005-05-20 18:30 ` Eli Zaretskii 0 siblings, 1 reply; 80+ messages in thread From: Daniel Jacobowitz @ 2005-05-20 18:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Vladimir Prus, gdb On Fri, May 20, 2005 at 06:54:13PM +0300, Eli Zaretskii wrote: > > From: Vladimir Prus <ghost@cs.msu.su> > > Date: Fri, 20 May 2005 18:45:22 +0400 > > > > Would not it be better to have a single "reverse" command which puts the > > debugger in "reverse" mode -- making step/stepi/next/nexti go backward. > > Daniel, I rest my case ;-) I don't rest mine :-) I admit I was a little surprised to see someone else suggest it, but I still think it's an awful idea as a user interface. While the "gear" switch is clever, a GUI might still want to use different icons for "next" and "rnext". And whichever way the GDB CLI and MI interfaces expose this functionality, a GUI can just as easily reuse the same buttons for both. The only advantage I see would be letting a GUI support it without having to know that the feature exists, by passing a command to GDB and then using the existing buttons. Seems of dubious use. I don't know yet whether direction during a debugging session is going to be persistant or frequently changing. Only one way to find out... -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 18:14 ` Daniel Jacobowitz @ 2005-05-20 18:30 ` Eli Zaretskii 0 siblings, 0 replies; 80+ messages in thread From: Eli Zaretskii @ 2005-05-20 18:30 UTC (permalink / raw) To: Vladimir Prus, gdb > Date: Fri, 20 May 2005 14:14:15 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com > > On Fri, May 20, 2005 at 06:54:13PM +0300, Eli Zaretskii wrote: > > > From: Vladimir Prus <ghost@cs.msu.su> > > > Date: Fri, 20 May 2005 18:45:22 +0400 > > > > > > Would not it be better to have a single "reverse" command which puts the > > > debugger in "reverse" mode -- making step/stepi/next/nexti go backward. > > > > Daniel, I rest my case ;-) > > I don't rest mine :-) I admit I was a little surprised to see someone > else suggest it, but I still think it's an awful idea as a user > interface. Just to clarify: ``my case'' was not to suggest to add this feature, but that someone some day might suggest to add it, and that such a suggestion might be accepted. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [discuss] Support for reverse-execution 2005-05-20 15:05 ` Vladimir Prus 2005-05-20 15:58 ` Eli Zaretskii @ 2005-05-20 19:27 ` Stan Shebs 1 sibling, 0 replies; 80+ messages in thread From: Stan Shebs @ 2005-05-20 19:27 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb Vladimir Prus wrote: > >Would not it be better to have a single "reverse" command which puts the >debugger in "reverse" mode -- making step/stepi/next/nexti go backward. > > In general, modes are bad for UI; people, even smart software engineers, are not good at remembering modes. Think of how many fenderbenders are caused by drivers stepping on the gas and going in the opposite direction of what they expected. Coming back to GDB, think of when you are using "up" and "down", then ask to print a variable and get a complaint there is no such variable, because you forgot which frame is current. So I think the basic commands should be "reverse-foo" or "back-foo" or whatever. That said, it would be pretty easy to layer a mode on top of those for experimentation purposes, let everybody try it out for awhile, and see what they tend to favor. For instance, I can see a usage where a user will want to go back and forth over a single complicated line multiple times, looking at different variables in each step/rstep pair. Stan ^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2005-05-23 19:39 UTC | newest] Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-19 1:23 [discuss] Support for reverse-execution Dan Shearer 2005-05-19 13:01 ` Johan Rydberg 2005-05-19 13:18 ` Daniel Jacobowitz 2005-05-19 13:47 ` Johan Rydberg 2005-05-20 10:37 ` Eli Zaretskii 2005-05-20 11:37 ` Andreas Schwab 2005-05-20 13:18 ` Daniel Jacobowitz 2005-05-20 13:36 ` Fabian Cenedese 2005-05-20 13:47 ` Daniel Jacobowitz 2005-05-20 14:41 ` Eli Zaretskii 2005-05-20 22:14 ` Daniel Jacobowitz 2005-05-20 12:22 ` Johan Rydberg 2005-05-20 13:19 ` Daniel Jacobowitz 2005-05-20 14:12 ` Eli Zaretskii 2005-05-20 13:14 ` Daniel Jacobowitz 2005-05-20 14:34 ` Eli Zaretskii 2005-05-20 15:40 ` Johan Rydberg 2005-05-20 10:47 ` Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2005-05-21 15:53 Paul Schlie 2005-05-20 22:11 Michael Snyder 2005-05-20 23:32 ` Paul Schlie 2005-05-20 21:59 Michael Snyder 2005-05-20 21:51 Michael Snyder 2005-05-21 9:44 ` Eli Zaretskii 2005-05-20 21:44 Michael Snyder 2005-05-20 21:25 Michael Snyder 2005-05-20 21:16 Michael Snyder 2005-05-20 21:31 ` Daniel Jacobowitz 2005-05-21 9:39 ` Eli Zaretskii 2005-05-23 18:19 ` Michael Snyder 2005-05-20 21:11 Michael Snyder 2005-05-20 21:27 ` Daniel Jacobowitz 2005-05-20 19:02 Michael Snyder 2005-05-20 20:43 ` Eli Zaretskii 2005-05-20 21:03 ` Michael Snyder 2005-05-20 15:49 Paul Schlie 2005-05-20 17:41 ` Dan Shearer 2005-05-20 22:01 ` Paul Schlie 2005-05-20 22:08 ` Daniel Jacobowitz 2005-05-20 22:43 ` Paul Schlie 2005-05-21 0:58 ` Daniel Jacobowitz 2005-05-21 1:42 ` Paul Schlie 2005-05-21 1:53 ` Daniel Jacobowitz 2005-05-21 1:56 ` Daniel Jacobowitz 2005-05-21 15:03 ` Paul Schlie 2005-05-21 14:13 ` Paul Schlie 2005-05-21 14:23 ` Daniel Jacobowitz 2005-05-21 15:04 ` Paul Schlie 2005-05-20 20:58 ` Michael Snyder 2005-05-20 21:35 ` Paul Schlie 2005-05-16 17:47 Dan Shearer 2005-05-16 18:04 ` Dan Shearer 2005-05-20 18:15 ` Daniel Jacobowitz 2005-05-21 0:05 ` Frank Ch. Eigler 2005-05-21 10:13 ` Eli Zaretskii 2005-05-21 10:28 ` Russell Shaw 2005-05-21 12:38 ` Eli Zaretskii 2005-05-21 12:55 ` Russell Shaw 2005-05-21 14:39 ` Russell Shaw 2005-05-21 14:19 ` Daniel Jacobowitz 2005-05-21 15:46 ` Eli Zaretskii 2005-05-21 17:43 ` Daniel Jacobowitz 2005-05-23 19:39 ` Dan Shearer 2005-05-12 23:08 Michael Snyder 2005-05-13 6:23 ` Eli Zaretskii 2005-05-19 13:46 ` Daniel Jacobowitz 2005-05-19 18:46 ` Michael Snyder 2005-05-19 19:26 ` Johan Rydberg 2005-05-20 10:55 ` Eli Zaretskii 2005-05-20 13:04 ` Daniel Jacobowitz 2005-05-20 14:30 ` Eli Zaretskii 2005-05-20 14:43 ` Andreas Schwab 2005-05-20 20:48 ` Michael Snyder 2005-05-20 20:51 ` Daniel Jacobowitz 2005-05-20 20:38 ` Michael Snyder 2005-05-20 15:05 ` Vladimir Prus 2005-05-20 15:58 ` Eli Zaretskii 2005-05-20 18:14 ` Daniel Jacobowitz 2005-05-20 18:30 ` Eli Zaretskii 2005-05-20 19:27 ` Stan Shebs
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).