reverse for GDB/MI

reverse for GDB/MI

[Tomas Holmberg]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

Hi,

I have looked at the new reverse functionality in GDB and I think that
it looks really good. I would like to see the reverse commands in the
GDB/MI interface as well. I have attached two patches with the same
purpose, to add reverse commands to the MI interface, as I am not sure
which one that is best.

/Tomas Holmberg

[-- Attachment #2: mi_reverse_ver0.diff --]
[-- Type: text/x-patch, Size: 1078 bytes --]

Index: gdb/mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.37
diff -c -p -r1.37 mi-cmds.c
*** gdb/mi/mi-cmds.c	17 Nov 2008 16:37:35 -0000	1.37
--- gdb/mi/mi-cmds.c	15 Dec 2008 09:54:10 -0000
*************** struct mi_cmd mi_cmds[] =
*** 70,75 ****
--- 70,81 ----
    { "exec-step", { NULL, 0 }, mi_cmd_exec_step},
    { "exec-step-instruction", { NULL, 0 }, mi_cmd_exec_step_instruction},
    { "exec-until", { "until", 1 }, NULL},
+   { "exec-reverse-continue", { "reverse-continue", 1 }, NULL},
+   { "exec-reverse-finish", { "reverse-finish", 1 }, NULL},
+   { "exec-reverse-next", { "reverse-next", 1 }, NULL},
+   { "exec-reverse-next-instruction", { "reverse-next-instruction", 1 }, NULL},
+   { "exec-reverse-step", { "reverse-step", 1 }, NULL},
+   { "exec-reverse-step-instruction", { "reverse-step-instruction", 1 }, NULL},
    { "file-clear", { NULL, 0 }, NULL },
    { "file-exec-and-symbols", { "file", 1 }, NULL },
    { "file-exec-file", { "exec-file", 1 }, NULL },

[-- Attachment #3: mi_reverse_ver1.diff --]
[-- Type: text/x-patch, Size: 4040 bytes --]

Index: gdb/mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.37
diff -c -p -r1.37 mi-cmds.c
*** gdb/mi/mi-cmds.c	17 Nov 2008 16:37:35 -0000	1.37
--- gdb/mi/mi-cmds.c	15 Dec 2008 09:57:08 -0000
*************** struct mi_cmd mi_cmds[] =
*** 70,75 ****
--- 70,81 ----
    { "exec-step", { NULL, 0 }, mi_cmd_exec_step},
    { "exec-step-instruction", { NULL, 0 }, mi_cmd_exec_step_instruction},
    { "exec-until", { "until", 1 }, NULL},
+   { "exec-reverse-continue", { NULL, 0 }, mi_cmd_exec_reverse_continue},
+   { "exec-reverse-finish", { NULL, 0 }, mi_cmd_exec_reverse_finish},
+   { "exec-reverse-next", { NULL, 0 }, mi_cmd_exec_reverse_next},
+   { "exec-reverse-next-instruction", { NULL, 0 }, mi_cmd_exec_reverse_next_instruction},
+   { "exec-reverse-step", { NULL, 0 }, mi_cmd_exec_reverse_step},
+   { "exec-reverse-step-instruction", { NULL, 0 }, mi_cmd_exec_reverse_step_instruction},
    { "file-clear", { NULL, 0 }, NULL },
    { "file-exec-and-symbols", { "file", 1 }, NULL },
    { "file-exec-file", { "exec-file", 1 }, NULL },
Index: gdb/mi/mi-cmds.h
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
retrieving revision 1.35
diff -c -p -r1.35 mi-cmds.h
*** gdb/mi/mi-cmds.h	17 Nov 2008 16:37:35 -0000	1.35
--- gdb/mi/mi-cmds.h	15 Dec 2008 09:57:08 -0000
*************** extern mi_cmd_argv_ftype mi_cmd_exec_ret
*** 59,64 ****
--- 59,70 ----
  extern mi_cmd_argv_ftype mi_cmd_exec_step;
  extern mi_cmd_argv_ftype mi_cmd_exec_step_instruction;
  extern mi_cmd_argv_ftype mi_cmd_exec_interrupt;
+ extern mi_cmd_argv_ftype mi_cmd_exec_reverse_continue;
+ extern mi_cmd_argv_ftype mi_cmd_exec_reverse_finish;
+ extern mi_cmd_argv_ftype mi_cmd_exec_reverse_next;
+ extern mi_cmd_argv_ftype mi_cmd_exec_reverse_next_instruction;
+ extern mi_cmd_argv_ftype mi_cmd_exec_reverse_step;
+ extern mi_cmd_argv_ftype mi_cmd_exec_reverse_step_instruction;
  extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
  extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_files;
  extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
Index: gdb/mi/mi-main.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
retrieving revision 1.139
diff -c -p -r1.139 mi-main.c
*** gdb/mi/mi-main.c	2 Dec 2008 15:52:15 -0000	1.139
--- gdb/mi/mi-main.c	15 Dec 2008 09:57:09 -0000
*************** mi_cmd_exec_interrupt (char *command, ch
*** 261,266 ****
--- 261,308 ----
      error ("Usage: -exec-interrupt [--all|--thread-group id]");
  }
  
+ void
+ mi_cmd_exec_reverse_continue (char *command, char **argv, int argc)
+ {
+   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
+   mi_execute_async_cli_command ("reverse-continue", argv, argc);
+ }
+ 
+ void
+ mi_cmd_exec_reverse_finish (char *command, char **argv, int argc)
+ {
+   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
+   mi_execute_async_cli_command ("reverse-finish", argv, argc);
+ }
+ 
+ void
+ mi_cmd_exec_reverse_next (char *command, char **argv, int argc)
+ {
+   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
+   mi_execute_async_cli_command ("reverse-next", argv, argc);
+ }
+ 
+ void
+ mi_cmd_exec_reverse_next_instruction (char *command, char **argv, int argc)
+ {
+   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
+   mi_execute_async_cli_command ("reverse-nexti", argv, argc);
+ }
+ 
+ void
+ mi_cmd_exec_reverse_step (char *command, char **argv, int argc)
+ {
+   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
+   mi_execute_async_cli_command ("reverse-step", argv, argc);
+ }
+ 
+ void
+ mi_cmd_exec_reverse_step_instruction (char *command, char **argv, int argc)
+ {
+   /* FIXME: Should call a libgdb function, not a cli wrapper.  */
+   mi_execute_async_cli_command ("reverse-stepi", argv, argc);
+ }
+ 
  static int
  find_thread_of_process (struct thread_info *ti, void *p)
  {

RE: reverse for GDB/MI

[Marc Khouzam]

Hi,

Looking forward to having MI support for reverse debugging.

One little annoying point is the command
-gdb-set exec-direction [forward | reverse]
When this command is issued, to be really correct, MI would need an
event to notify a frontend that the exec-direction has changed.
This is in case the exec-direction is changed in the console or from
another window.

Another option, to avoid adding a new event, is if we could disable the
changing of exec-direction when running in MI, and simulate it in the
frontend.
The frontend could simply keep track of the exec-direction chosen by the
user 
and issue reverse commands or forward commands, appropriately.

Just a thought.

marc



> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Tomas Holmberg
> Sent: Monday, December 15, 2008 5:59 AM
> To: gdb-patches@sourceware.org; Michael Snyder
> Subject: reverse for GDB/MI
> 
> Hi,
> 
> I have looked at the new reverse functionality in GDB and I think that
> it looks really good. I would like to see the reverse commands in the
> GDB/MI interface as well. I have attached two patches with the same
> purpose, to add reverse commands to the MI interface, as I am not sure
> which one that is best.
> 
> /Tomas Holmberg
> 

RE: reverse for GDB/MI

[Jakob Engblom]

> One little annoying point is the command
> -gdb-set exec-direction [forward | reverse]
> When this command is issued, to be really correct, MI would need an
> event to notify a frontend that the exec-direction has changed.
> This is in case the exec-direction is changed in the console or from
> another window.

This is to retain compatibility with the normal gdb command-line commands for
reversing. According to an earlier discussion in October, this command was part
of the Michael Snyder patches to support rev exec, and it was decided then not
to change the commands. 
 
> Another option, to avoid adding a new event, is if we could disable the
> changing of exec-direction when running in MI, and simulate it in the
> frontend.
> The frontend could simply keep track of the exec-direction chosen by the
> user
> and issue reverse commands or forward commands, appropriately.

The simplest solution is to have no "direction" at all, but just a set of
reverse-X and forward-X commands.  But that is not inline with the main gdb user
interface as it stands currently as we understand it. 

Happy to change it, if needed.

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47    
Drottningholmsvägen 14      Mobile: +46 709 242 646   
11243 Stockholm             Web:    www.virtutech.com  
Sweden
________________________________________________________
 

RE: reverse for GDB/MI

[Marc Khouzam]

 

> From: Jakob Engblom [mailto:jakob@virtutech.com] 
> Sent: Tuesday, December 16, 2008 3:44 AM
> 
> > One little annoying point is the command
> > -gdb-set exec-direction [forward | reverse]
> > When this command is issued, to be really correct, MI would need an
> > event to notify a frontend that the exec-direction has changed.
> > This is in case the exec-direction is changed in the console or from
> > another window.
> 
> This is to retain compatibility with the normal gdb 
> command-line commands for
> reversing. According to an earlier discussion in October, 
> this command was part
> of the Michael Snyder patches to support rev exec, and it was 
> decided then not
> to change the commands. 
>  
> > Another option, to avoid adding a new event, is if we could 
> disable the
> > changing of exec-direction when running in MI, and simulate 
> it in the
> > frontend.
> > The frontend could simply keep track of the exec-direction 
> chosen by the
> > user
> > and issue reverse commands or forward commands, appropriately.
> 
> The simplest solution is to have no "direction" at all, but 
> just a set of
> reverse-X and forward-X commands.  But that is not inline 
> with the main gdb user
> interface as it stands currently as we understand it. 

I think it is nice from a user's perspective to have the two
approaches to reverse debugging.  So, I actually like
the exec-direction command from a CLI perspective.  It was
for MI, that I felt it caused complications.

But now that I think about it, DSF-GDB provides a console
to the user, which can accept CLI commands.  Therefore, I can
imagine that if the user has set the exec-direction to reverse
(even through the Eclipse UI), he would expect 'next' and 'step' 
to work backwards if typed in the console.

Sigh... So, I think that the best solution for MI is to have
an event to indicate a change of exec-direction.  Disabling that
toggle like I originally suggested could still work but would require
the frontend to simulated it by also converting 'next' into
'reverse-next'
when typed in the command line, which is getting ugly...

Marc

Re: reverse for GDB/MI

[Eli Zaretskii]

> Date: Mon, 15 Dec 2008 11:58:56 +0100
> From: Tomas Holmberg <th@virtutech.com>
> 
> I have looked at the new reverse functionality in GDB and I think that
> it looks really good. I would like to see the reverse commands in the
> GDB/MI interface as well. I have attached two patches with the same
> purpose, to add reverse commands to the MI interface, as I am not sure
> which one that is best.

Thanks, but please also submit a suitable change for the manual.

Re: reverse for GDB/MI

[Tomas Holmberg]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

> Thanks, but please also submit a suitable change for the manual.
Documentation for reverse MI commands attached.

/tomas


[-- Attachment #2: gdb.texinfo.rev_mi.txt --]
[-- Type: text/plain, Size: 5471 bytes --]

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.541
diff -u -r1.541 gdb.texinfo
--- gdb.texinfo	16 Dec 2008 06:14:00 -0000	1.541
+++ gdb.texinfo	17 Dec 2008 14:47:26 -0000
@@ -20813,6 +20813,212 @@
 @end smallexample
 
 
+@subheading The @code{-exec-reverse-continue} Command
+@findex -exec-reverse-continue
+
+@subsubheading Synopsis
+
+@smallexample
+ -exec-reverse-continue
+@end smallexample
+
+Resumes the reverse execution of the inferior program until a
+breakpoint is encountered, or until the inferior exits.
+
+@subsubheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{reverse-continue}.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-exec-reverse-continue
+^running
+*running,thread-id="all"
+(gdb)
+*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",
+thread-id="1",stopped-threads="all",
+frame=@{addr="0x10000560",func="mark",args=[],file="debug_example.c",
+fullname="/home/th/debug_example.c",line="19"@}
+(gdb)
+@end smallexample
+
+
+@subheading The @code{-exec-reverse-finish} Command
+@findex -exec-reverse-finish
+
+@subsubheading Synopsis
+
+@smallexample
+ -exec-reverse-finish
+@end smallexample
+
+Resumes the reverse execution of the inferior program until the point
+where current function was called.
+
+@subsubheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{reverse-finish}.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-exec-step
+^running
+*running,thread-id="all"
+(gdb)
+*stopped,reason="end-stepping-range",thread-id="1",stopped-threads="all",
+frame=@{addr="0x10000580",func="mark",args=[],file="debug_example.c",
+fullname="/home/th/debug_example.c",line="20"@}
+(gdb)
+-exec-reverse-finish
+^running
+*running,thread-id="all"
+(gdb)
+*stopped
+*running,thread-id="all"
+*stopped,reason="end-stepping-range",thread-id="1",stopped-threads="all",
+frame=@{addr="0x1000070c",func="main",args=[],
+file="debug_example.c",fullname="/home/th/debug_example.c",line="52"@}
+(gdb)
+@end smallexample
+
+
+@subheading The @code{-exec-reverse-next} Command
+@findex -exec-reverse-next
+
+@subsubheading Synopsis
+
+@smallexample
+ -exec-reverse-next
+@end smallexample
+
+Resumes reverse execution of the inferior program, stopping at the
+beginning of the previous source line. Starting from the first line of
+a function, the command will take you back to the caller of that
+function, before the function was called.
+
+@subsubheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{reverse-next}.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-exec-reverse-next
+^running
+*running,thread-id="all"
+(gdb)
+*stopped,reason="end-stepping-range",
+thread-id="1",stopped-threads="all",
+frame=@{addr="0x100006f4",func="main",args=[],
+file="debug_example.c",fullname="/home/th/debug_example.c",line="52"@}
+(gdb)
+@end smallexample
+
+
+@subheading The @code{-exec-reverse-next-instruction} Command
+@findex -exec-reverse-next-instruction
+
+@subsubheading Synopsis
+
+@smallexample
+ -exec-reverse-next-instruction
+@end smallexample
+
+Resumes reverse execution of the inferior program, stopping at the
+previous instruction. If the previously executed instruction was a
+return from another instruction, it will continue to execute in
+reverse until the call to that function (from the current stack frame)
+is reached.
+
+@subsubheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{reverse-nexti}.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-exec-reverse-next-instruction
+^running
+*running,thread-id="all"
+(gdb)
+*stopped,reason="end-stepping-range",
+thread-id="1",stopped-threads="all",
+frame=@{addr="0x100006f4",func="main",args=[],
+file="debug_example.c",fullname="/home/th/debug_example.c",line="52"@}
+(gdb)
+@end smallexample
+
+
+@subheading The @code{-exec-reverse-step} Command
+@findex -exec-reverse-step
+
+@subsubheading Synopsis
+
+@smallexample
+ -exec-reverse-step
+@end smallexample
+
+Resumes reverse execution of the inferior program, stopping at the
+beginning of the previously executed source line.
+
+@subsubheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{reverse-step}.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-exec-reverse-step
+^running
+*running,thread-id="all"
+(gdb)
+*stopped,reason="end-stepping-range",
+thread-id="1",stopped-threads="all",
+frame=@{addr="0x100006d8",func="main",args=[],
+file="debug_example.c",fullname="/home/th/debug_example.c",line="51"@}
+(gdb)
+@end smallexample
+
+
+@subheading The @code{-exec-reverse-step-instruction} Command
+@findex -exec-reverse-step-instruction
+
+@subsubheading Synopsis
+
+@smallexample
+ -exec-reverse-step-instruction
+@end smallexample
+
+Resumes reverse execution of the inferior program, stopping at the
+previously executed instruction.
+
+@subsubheading @value{GDBN} Command
+
+The corresponding @value{GDBN} command is @samp{reverse-stepi}.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-exec-reverse-step-instruction
+^running
+*running,thread-id="all"
+(gdb)
+*stopped,reason="end-stepping-range",
+thread-id="1",stopped-threads="all",
+frame=@{addr="0x100006d8",func="main",args=[],
+file="debug_example.c",fullname="/home/th/debug_example.c",line="51"@}
+(gdb)
+@end smallexample
+
+
 @subheading The @code{-exec-run} Command
 @findex -exec-run
 

Re: reverse for GDB/MI

[Eli Zaretskii]

> Date: Wed, 17 Dec 2008 15:56:22 +0100
> From: Tomas Holmberg <th@virtutech.com>
> CC: gdb-patches@sourceware.org, msnyder@vmware.com
> 
> > Thanks, but please also submit a suitable change for the manual.
> Documentation for reverse MI commands attached.

Thanks.

> +(gdb)

This should be "(@value{GDBP})", not a literal "(gdb)" (here and
elsewhere in your patch).

> +beginning of the previous source line. Starting from the first line of
                                        ^^
Please make sure there are 2 spaces after a period that ends a
sentence.

Other than that, this patch is fine with me.

Re: reverse for GDB/MI

[Vladimir Prus]

Tomas Holmberg wrote:

> Hi,
> 
> I have looked at the new reverse functionality in GDB and I think that
> it looks really good. I would like to see the reverse commands in the
> GDB/MI interface as well. I have attached two patches with the same
> purpose, to add reverse commands to the MI interface, as I am not sure
> which one that is best.

On the low level, the patch that introduces new functions is right --
I think that commands that route to CLI commands use bogus quoting.

I am not quite sure about adding new set of commands for that. Can we use
--reverse option, thereby not introducing new commands?

- Volodya

Re: reverse for GDB/MI

[Tomas Holmberg]

> I am not quite sure about adding new set of commands for that. Can we use
> --reverse option, thereby not introducing new commands?

Adding a reverse option to the existing commands is possible. But I do
not think it is a good idea. It is not always obvious what should
happen when running a standard command in reverse. I consider the
reverse commands as a new set commands and not a variant of the old.

/tomas

Re: reverse for GDB/MI

[Vladimir Prus]

Tomas Holmberg wrote:

>> I am not quite sure about adding new set of commands for that. Can we use
>> --reverse option, thereby not introducing new commands?
> 
> Adding a reverse option to the existing commands is possible. But I do
> not think it is a good idea. It is not always obvious what should
> happen when running a standard command in reverse. 

Why? -exec-step always steps forward. -exec-step --reverse always steps
backward. Seems like a fairly simple model to me.

- Volodya

RE: reverse for GDB/MI

[Jakob Engblom]

> >> I am not quite sure about adding new set of commands for that. Can we use
> >> --reverse option, thereby not introducing new commands?

What would be the gain from NOT adding the commands, as you see it? It certainly
looks like the most straightforward and easy-to-understand solution. 

> >
> > Adding a reverse option to the existing commands is possible. But I do
> > not think it is a good idea. It is not always obvious what should
> > happen when running a standard command in reverse.
> 
> Why? -exec-step always steps forward. -exec-step --reverse always steps
> backward. Seems like a fairly simple model to me.

Overall, it is not that simple, unfortunately, and that is our experience from
doing reverse execution on a large scale for the past four years. 

First of all, the logic in the implementation side is very different for forward
and backward step.  Second, going into that logic is simpler with a separate set
of commands -- much easier both to send out and parse in the code, as the
reverse bits are obviously separated.  Having a --reverse flag will force
command handlers that only deal with the normal case to check for reverse and
either return an error or take some other action. Why complicate it like that?
If you cannot do reverse, having a set of reverse commands that is clearly
defined by looking just at the command makes ignoring them easier.   There is no
shortage of name space in MI, and thus I cannot see that there is any value to
making things more complicated with an extra flag. 

This is also inline with the gdb command line structure, and I think it eases
understanding the system as a whole if all command interfaces use a similar
semantic structure. 

Note that on a conceptual level there are new possibilities in reverse execution
that do not exist in classic unidirectional debugging. For example, "go to time
point P".  Since a classic unidirectional debugger can only stop or go forward,
this concept did not exist in such a form.  This is not part of the current
patch, but certainly can be seen to come up moving forward (or it might be
already part of bookmarking in the reverse gdb). 


Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47    
Drottningholmsvägen 14      Mobile: +46 709 242 646   
11243 Stockholm             Web:    www.virtutech.com  
Sweden
________________________________________________________
 

Re: reverse for GDB/MI

[Vladimir Prus]

On Thursday 18 December 2008 12:15:29 Jakob Engblom wrote:
> > >> I am not quite sure about adding new set of commands for that. Can we use
> > >> --reverse option, thereby not introducing new commands?
> 
> What would be the gain from NOT adding the commands, as you see it? It certainly
> looks like the most straightforward and easy-to-understand solution. 
> 
> > >
> > > Adding a reverse option to the existing commands is possible. But I do
> > > not think it is a good idea. It is not always obvious what should
> > > happen when running a standard command in reverse.
> > 
> > Why? -exec-step always steps forward. -exec-step --reverse always steps
> > backward. Seems like a fairly simple model to me.
> 
> Overall, it is not that simple, unfortunately, and that is our experience from
> doing reverse execution on a large scale for the past four years. 
>
> First of all, the logic in the implementation side is very different for forward
> and backward step.  Second, going into that logic is simpler with a separate set
> of commands -- much easier both to send out and parse in the code, as the
> reverse bits are obviously separated.  Having a --reverse flag will force
> command handlers that only deal with the normal case to check for reverse and
> either return an error or take some other action. Why complicate it like that?

I assume that the 'set exec-direction' command happens to already work in FSF GDB?
Then, I'd claim that --reverse is actually trivial.

> If you cannot do reverse, having a set of reverse commands that is clearly
> defined by looking just at the command makes ignoring them easier.   

Ignoring where, by whom, and for what purpose?

> There is no 
> shortage of name space in MI, and thus I cannot see that there is any value to
> making things more complicated with an extra flag.

It seems to be that it's best to have some structure in MI commands and flags.
Say, we have continue and reverse-continue. What if you want some other form
of continue, say "continue for N seconds". Should we have then:

	continue
	reverse-continue
	timed-continue
	reverse-timed-continue

? That would be fairly cumbersome. Also, the --reverse option can be documented
with a single paragraph, whilst individual commands should all have individual
documentation.
 
> This is also inline with the gdb command line structure, and I think it eases
> understanding the system as a whole if all command interfaces use a similar
> semantic structure. 
> 
> Note that on a conceptual level there are new possibilities in reverse execution
> that do not exist in classic unidirectional debugging. For example, "go to time
> point P".  Since a classic unidirectional debugger can only stop or go forward,
> this concept did not exist in such a form.  This is not part of the current
> patch, but certainly can be seen to come up moving forward (or it might be
> already part of bookmarking in the reverse gdb). 

To summarize, I would like the patch to be adjusted in the following way:

	1. Use --reverse option
	2. Arrange for --exec-step, and similar, to ignore 'set exec-direction',
	since all new MI commands should strive to be stateless. This, of course,
	will mean that one cannot get existing frontend to do reverse step by
	typing a command into CLI console, but it is not obvious if existing
	frontend will work without modification anyway.
	3. Include documentation
	4. Include testcases

Thanks,
Volodya

Re: reverse for GDB/MI

[Doug Evans]

On Thu, Feb 5, 2009 at 1:39 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
> It seems to be that it's best to have some structure in MI commands and flags.
> Say, we have continue and reverse-continue. What if you want some other form
> of continue, say "continue for N seconds". Should we have then:
>
>        continue
>        reverse-continue
>        timed-continue
>        reverse-timed-continue
>
> ? That would be fairly cumbersome. Also, the --reverse option can be documented
> with a single paragraph, whilst individual commands should all have individual
> documentation.

timed-continue could take a negative argument to go backwards.

[fwiw, I'm in the camp that dislikes --reverse too]

> To summarize, I would like the patch to be adjusted in the following way:
>
>        1. Use --reverse option
>        2. Arrange for --exec-step, and similar, to ignore 'set exec-direction',
>        since all new MI commands should strive to be stateless. This, of course,
>        will mean that one cannot get existing frontend to do reverse step by
>        typing a command into CLI console, but it is not obvious if existing
>        frontend will work without modification anyway.

Can we remove exec-direction altogether?
1/2 :-)

RE: reverse for GDB/MI

[Jakob Engblom]

> 	1. Use --reverse option

It looks like we are back to the --reverse discussion that we had before
Christmas. Most people seem to think that having specialized commands for
reverse execution makes more sense than having a special flag to certain
commands. 

For example, Michael Snyder wrote on 2008-12-18:
http://sourceware.org/ml/gdb-patches/2008-12/msg00351.html : 
----
> There are other reverse commands than the -exec-reverse-step that are more
> complicated. If you consider all reverse commands to be simple variants
> of the forward commands, then you are correct that there should just
> be a --reverse option. But I consider them to not be simple variants.

They're not simple variants.  Some of them have to deal with
issues like prologues vs. epilogues, stepping thru a return
back to the callee, etc.

It's mostly handled in infrun and infcmd, by checking the
"exec-direction" flag.

> You can also look at the documentation to see if the reverse commands are
> just variants of the forward variants. I do not think we can replace the
> documentation for reverse-step, reverse-step-instruction, reverse-continue,
> reverse-finish, reverse-next, and reverse-next-instruction and just say it
> is the reverse variant for the corresponding forward commands. Please look
> at the other reverse commands and see if you can say "reverse-finish" is
> just the reverse variant of finish.

Yeah -- it's not.  ;-)
It's an analogue, that's all.
----


And Tomas Holmberg: http://sourceware.org/ml/gdb-patches/2008-12/msg00319.html :
----
    I am not quite sure about adding new set of commands for that. Can we use
    --reverse option, thereby not introducing new commands?


Adding a reverse option to the existing commands is possible. But I do
not think it is a good idea. It is not always obvious what should
happen when running a standard command in reverse. I consider the
reverse commands as a new set commands and not a variant of the old.
----

Also, changing to variants would require rewriting code that we already have in
place and hvae tested (at least to some extent), and doing that always strikes
me as inviting problems and extra work.  

About the proliferation of commands, that seems to be in the nature of things
for reverse. The commands discussed here:

> 	continue
> 	reverse-continue
> 	timed-continue
> 	reverse-timed-continue

That is how we actually do things in Simics, and it turns out to be pretty
useful.  In our CLI, we have:

For basic control:

* continue [n]
* reverse  [n]
* run-seconds (value)
* reverse-to (value)
* skip-to (point in time)
* stepi [n]
* reverse-stepi [n]

And with debug info loaded:
* reverse-next-instruction  
* reverse-step-line       
* reverse-next-line         
* uncall-function


> 	3. Include documentation

Documentation for the reverse commands was submitted back in December too, as
far as I can tell (http://sourceware.org/ml/gdb-patches/2008-12/msg00312.html).
Did that miss being included into the source code?  

> 	2. Arrange for --exec-step, and similar, to ignore 'set exec-direction',
> 	since all new MI commands should strive to be stateless. This, of
course,
> 	will mean that one cannot get existing frontend to do reverse step by
> 	typing a command into CLI console, but it is not obvious if existing
> 	frontend will work without modification anyway.

That makes sense to me too, the exec-direction concept is a bit strange.

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47   
Drottningholmsvägen 22      Mobile: +46 709 242 646  
11243 Stockholm             Web:    www.virtutech.com 
Sweden
________________________________________________________
  

Re: reverse for GDB/MI

[Vladimir Prus]

On Friday 06 February 2009 13:07:32 Jakob Engblom wrote:
> > 	1. Use --reverse option
>
> It looks like we are back to the --reverse discussion that we had before
> Christmas. 

Right, because no conclusion was ever reached on that discussion, to the
best of my knowledge.

> Most people seem to think that having specialized commands for
> reverse execution makes more sense than having a special flag to certain
> commands.
>
> For example, Michael Snyder wrote on 2008-12-18:
> http://sourceware.org/ml/gdb-patches/2008-12/msg00351.html :
> ----
>
> > There are other reverse commands than the -exec-reverse-step that are
> > more complicated. If you consider all reverse commands to be simple
> > variants of the forward commands, then you are correct that there should
> > just be a --reverse option. But I consider them to not be simple
> > variants.
>
> They're not simple variants.  Some of them have to deal with
> issues like prologues vs. epilogues, stepping thru a return
> back to the callee, etc.
>
> It's mostly handled in infrun and infcmd, by checking the
> "exec-direction" flag.
>
> > You can also look at the documentation to see if the reverse commands are
> > just variants of the forward variants. I do not think we can replace the
> > documentation for reverse-step, reverse-step-instruction,
> > reverse-continue, reverse-finish, reverse-next, and
> > reverse-next-instruction and just say it is the reverse variant for the
> > corresponding forward commands. Please look at the other reverse commands
> > and see if you can say "reverse-finish" is just the reverse variant of
> > finish.
>
> Yeah -- it's not.  ;-)
> It's an analogue, that's all.
> ----
>
>
> And Tomas Holmberg:
> http://sourceware.org/ml/gdb-patches/2008-12/msg00319.html : ----
>     I am not quite sure about adding new set of commands for that. Can we
> use --reverse option, thereby not introducing new commands?
>
>
> Adding a reverse option to the existing commands is possible. But I do
> not think it is a good idea. It is not always obvious what should
> happen when running a standard command in reverse. I consider the
> reverse commands as a new set commands and not a variant of the old.

I saw both these comments, and I still think that 'continue', for frontend,
is continue, no matter if that's going backward to some point in time, or just 
forward. Frontend does not care about prologues and epilogues, and stepping
back to caller, and anything like this.



> ----
>
> Also, changing to variants would require rewriting code that we already
> have in place and hvae tested (at least to some extent), and doing that
> always strikes me as inviting problems and extra work.

Well, I don't remember that the design for MI reverse support was ever posted
to this list. If it were, you'd receive these comments before writing the code 
:-)

>
> About the proliferation of commands, that seems to be in the nature of
> things
>
> for reverse. The commands discussed here:
> > 	continue
> > 	reverse-continue
> > 	timed-continue
> > 	reverse-timed-continue
>
> That is how we actually do things in Simics, and it turns out to be pretty
> useful.  In our CLI, we have:
>
> For basic control:
>
> * continue [n]
> * reverse  [n]
> * run-seconds (value)
> * reverse-to (value)
> * skip-to (point in time)
> * stepi [n]
> * reverse-stepi [n]
>
> And with debug info loaded:
> * reverse-next-instruction
> * reverse-step-line
> * reverse-next-line
> * uncall-function

Well, this sounds fairly complicated to me.

>
> > 	3. Include documentation
>
> Documentation for the reverse commands was submitted back in December too,
> as far as I can tell
> (http://sourceware.org/ml/gdb-patches/2008-12/msg00312.html). Did that miss
> being included into the source code?

I've missed that post on the first re-read of this thread.

> > 	2. Arrange for --exec-step, and similar, to ignore 'set exec-direction',
> > 	since all new MI commands should strive to be stateless. This, of
>
> course,
>
> > 	will mean that one cannot get existing frontend to do reverse step by
> > 	typing a command into CLI console, but it is not obvious if existing
> > 	frontend will work without modification anyway.
>
> That makes sense to me too, the exec-direction concept is a bit strange.

Note that I have no position if exec-direction should remain in CLI, I just 
prefer that it does not affect MI.

- Volodya

RE: reverse for GDB/MI

[Jakob Engblom]

> > Also, changing to variants would require rewriting code that we already
> > have in place and hvae tested (at least to some extent), and doing that
> > always strikes me as inviting problems and extra work.
> 
> Well, I don't remember that the design for MI reverse support was ever posted
> to this list. If it were, you'd receive these comments before writing the code
> :-)

The patch for the MI commands was the implementation I mention, and it seems that it has been used by Teawater as well for some kind of testing.  We have also tested them out and used them for a quite a while, as a patch to gdb used with Simics.  So in that sense, the MI commands are not newly invented, but rather a commit of something that we have been using for a few years already.  

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47   
Drottningholmsvägen 22      Mobile: +46 709 242 646  
11243 Stockholm             Web:    www.virtutech.com 
Sweden
________________________________________________________
  

Re: reverse for GDB/MI

[Tomas Holmberg]

Vladimir Prus wrote:
> Tomas Holmberg wrote:
> 
>>> I am not quite sure about adding new set of commands for that. Can we use
>>> --reverse option, thereby not introducing new commands?
>> Adding a reverse option to the existing commands is possible. But I do
>> not think it is a good idea. It is not always obvious what should
>> happen when running a standard command in reverse. 
> 
> Why? -exec-step always steps forward. -exec-step --reverse always steps
> backward. Seems like a fairly simple model to me.

There are other reverse commands than the -exec-reverse-step that are more
complicated. If you consider all reverse commands to be simple variants
of the forward commands, then you are correct that there should just
be a --reverse option. But I consider them to not be simple variants.

You can also look at the documentation to see if the reverse commands are
just variants of the forward variants. I do not think we can replace the
documentation for reverse-step, reverse-step-instruction, reverse-continue,
reverse-finish, reverse-next, and reverse-next-instruction and just say it
is the reverse variant for the corresponding forward commands. Please look
at the other reverse commands and see if you can say "reverse-finish" is
just the reverse variant of finish.

/tomas

Re: reverse for GDB/MI

[Joel Brobecker]

> You can also look at the documentation to see if the reverse commands are
> just variants of the forward variants. I do not think we can replace the
> documentation for reverse-step, reverse-step-instruction, reverse-continue,
> reverse-finish, reverse-next, and reverse-next-instruction and just say it
> is the reverse variant for the corresponding forward commands. Please look
> at the other reverse commands and see if you can say "reverse-finish" is
> just the reverse variant of finish.

When I reviewed the patches that introduced the generic mechanics for
reverse debugging, I remember that some cases were particularly
difficult to understand; or in other words, it was difficult to
understand what we were supposed to do. Finish was one of the commands
that were tricky to "reverse", I remember this example clearly.

-- 
Joel

Re: reverse for GDB/MI

[Pedro Alves]

On Friday 19 December 2008 11:06:36, Joel Brobecker wrote:
> > You can also look at the documentation to see if the reverse commands are
> > just variants of the forward variants. I do not think we can replace the
> > documentation for reverse-step, reverse-step-instruction, reverse-continue,
> > reverse-finish, reverse-next, and reverse-next-instruction and just say it
> > is the reverse variant for the corresponding forward commands. Please look
> > at the other reverse commands and see if you can say "reverse-finish" is
> > just the reverse variant of finish.
> 
> When I reviewed the patches that introduced the generic mechanics for
> reverse debugging, I remember that some cases were particularly
> difficult to understand; or in other words, it was difficult to
> understand what we were supposed to do. Finish was one of the commands
> that were tricky to "reverse", I remember this example clearly.
> 

Me too.  It's confusing because "reverse-finish" isn't really doing a reverse
"finish".  If it were, a "finish", followed by a "reverse-finish" (or the
other way around) would bring you to the original state, like a "step" followed by
a "reverse-step" tries to (it can't be 100% accurate, but still).

 A -> step -> B -> reverse-step -> A
 A -> reverse-step -> C -> step -> A
 A -> finish -> D -> reverse-finish -> E

I think someone just proposed to rename "reverse-finish" to "uncall", that although
may sound weird at first, states much clearly what the "reverse-finish" command
really does.

-- 
Pedro Alves

RE: reverse for GDB/MI

[Jakob Engblom]

> Me too.  It's confusing because "reverse-finish" isn't really doing a reverse
> "finish".  If it were, a "finish", followed by a "reverse-finish" (or the
> other way around) would bring you to the original state, like a "step"
followed
> by
> a "reverse-step" tries to (it can't be 100% accurate, but still).

Good point.  Reverse-x naming works when x and rev-x cancel each other. Which is
pretty much limited to instruction step or moving a certain number of machine
instructions forward or backward.  On source level, you get other expected
behavior. 

For example, if you have

A;
Call(b);
C;

And sit at "C" and do a reverse-step, you might well end up at A as that is
stepping back in the same function.  While inside b, doing a step that hits a
return will put you at C, but unstepping is then contrained to do so in the
scope you are in.  Anything else than instruction back or forward can have
asymmetric behavior due to the way function scope affect the behavior of
debugging commands.

> I think someone just proposed to rename "reverse-finish" to "uncall", that
> although
> may sound weird at first, states much clearly what the "reverse-finish"
command
> really does.

Uncall is a good name, as it makes it much clearer what is going on.

/jakob

Re: reverse for GDB/MI

[Michael Snyder]

Tomas Holmberg wrote:
> Vladimir Prus wrote:
>> Tomas Holmberg wrote:
>>
>>>> I am not quite sure about adding new set of commands for that. Can we use
>>>> --reverse option, thereby not introducing new commands?
>>> Adding a reverse option to the existing commands is possible. But I do
>>> not think it is a good idea. It is not always obvious what should
>>> happen when running a standard command in reverse. 
>> Why? -exec-step always steps forward. -exec-step --reverse always steps
>> backward. Seems like a fairly simple model to me.
> 
> There are other reverse commands than the -exec-reverse-step that are more
> complicated. If you consider all reverse commands to be simple variants
> of the forward commands, then you are correct that there should just
> be a --reverse option. But I consider them to not be simple variants.

They're not simple variants.  Some of them have to deal with
issues like prologues vs. epilogues, stepping thru a return
back to the callee, etc.

It's mostly handled in infrun and infcmd, by checking the
"exec-direction" flag.

> You can also look at the documentation to see if the reverse commands are
> just variants of the forward variants. I do not think we can replace the
> documentation for reverse-step, reverse-step-instruction, reverse-continue,
> reverse-finish, reverse-next, and reverse-next-instruction and just say it
> is the reverse variant for the corresponding forward commands. Please look
> at the other reverse commands and see if you can say "reverse-finish" is
> just the reverse variant of finish.

Yeah -- it's not.  ;-)
It's an analogue, that's all.

RE: reverse for GDB/MI

[Marc Khouzam]

Hi,

It was pointed out to me that people who have been doing reversible
debug for a while seems to 
have specific commands for reverse debugging and they do have a command
for "go to time point P".
For example http://www.undo-software.com/undodb_man.html:

bgoton <number> 
Move forwards or backwards to the specified time, in simulated
nanoseconds. 
bgoton +<number> | -<number> 
Step forward/backward the specified number of simulated nanoseconds.  

Marc


> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Michael Snyder
> Sent: Friday, December 19, 2008 2:06 PM
> To: Tomas Holmberg
> Cc: Vladimir Prus; gdb-patches@sources.redhat.com
> Subject: Re: reverse for GDB/MI
> 
> Tomas Holmberg wrote:
> > Vladimir Prus wrote:
> >> Tomas Holmberg wrote:
> >>
> >>>> I am not quite sure about adding new set of commands for 
> that. Can we use
> >>>> --reverse option, thereby not introducing new commands?
> >>> Adding a reverse option to the existing commands is 
> possible. But I do
> >>> not think it is a good idea. It is not always obvious what should
> >>> happen when running a standard command in reverse. 
> >> Why? -exec-step always steps forward. -exec-step --reverse 
> always steps
> >> backward. Seems like a fairly simple model to me.
> > 
> > There are other reverse commands than the 
> -exec-reverse-step that are more
> > complicated. If you consider all reverse commands to be 
> simple variants
> > of the forward commands, then you are correct that there should just
> > be a --reverse option. But I consider them to not be simple 
> variants.
> 
> They're not simple variants.  Some of them have to deal with
> issues like prologues vs. epilogues, stepping thru a return
> back to the callee, etc.
> 
> It's mostly handled in infrun and infcmd, by checking the
> "exec-direction" flag.
> 
> > You can also look at the documentation to see if the 
> reverse commands are
> > just variants of the forward variants. I do not think we 
> can replace the
> > documentation for reverse-step, reverse-step-instruction, 
> reverse-continue,
> > reverse-finish, reverse-next, and reverse-next-instruction 
> and just say it
> > is the reverse variant for the corresponding forward 
> commands. Please look
> > at the other reverse commands and see if you can say 
> "reverse-finish" is
> > just the reverse variant of finish.
> 
> Yeah -- it's not.  ;-)
> It's an analogue, that's all.
> 

Re: reverse for GDB/MI

[Michael Snyder]

Marc Khouzam wrote:
> Hi,
> 
> It was pointed out to me that people who have been doing reversible
> debug for a while seems to 
> have specific commands for reverse debugging and they do have a command
> for "go to time point P".
> For example http://www.undo-software.com/undodb_man.html:
> 
> bgoton <number> 
> Move forwards or backwards to the specified time, in simulated
> nanoseconds. 
> bgoton +<number> | -<number> 
> Step forward/backward the specified number of simulated nanoseconds.  

I think that's a great idea, but
a) it seems a bit tangential to this thread, since it would
not simply be an addition to MI, but to the CLI as well, and
b) gdb currently has no concept of a time point or execution
point, so we would have to discuss how to define one.

RE: reverse for GDB/MI

[Marc Khouzam]

I was mostly trying to give more weight to the argument
that reverse commands are not necessarily the mirror
image of forward commands, since reverse debugging
opens the door to entirely new commands.
Implementing those commands is another point though :-)

 

> -----Original Message-----
> From: Michael Snyder [mailto:msnyder@vmware.com] 
> Sent: Monday, December 22, 2008 4:08 PM
> To: Marc Khouzam
> Cc: Tomas Holmberg; Vladimir Prus; gdb-patches@sources.redhat.com
> Subject: Re: reverse for GDB/MI
> 
> Marc Khouzam wrote:
> > Hi,
> > 
> > It was pointed out to me that people who have been doing reversible
> > debug for a while seems to 
> > have specific commands for reverse debugging and they do 
> have a command
> > for "go to time point P".
> > For example http://www.undo-software.com/undodb_man.html:
> > 
> > bgoton <number> 
> > Move forwards or backwards to the specified time, in simulated
> > nanoseconds. 
> > bgoton +<number> | -<number> 
> > Step forward/backward the specified number of simulated 
> nanoseconds.  
> 
> I think that's a great idea, but
> a) it seems a bit tangential to this thread, since it would
> not simply be an addition to MI, but to the CLI as well, and
> b) gdb currently has no concept of a time point or execution
> point, so we would have to discuss how to define one.
> 
> 

RE: reverse for GDB/MI

[Jakob Engblom]

 
> Hi,
> 
> It was pointed out to me that people who have been doing reversible
> debug for a while seems to
> have specific commands for reverse debugging and they do have a command
> for "go to time point P".
> For example http://www.undo-software.com/undodb_man.html:
> 
> bgoton <number>
> Move forwards or backwards to the specified time, in simulated
> nanoseconds.
> bgoton +<number> | -<number>
> Step forward/backward the specified number of simulated nanoseconds.

Simics has it to, in some different ways:

skip-to <bookmark> 
reverse n time units
continue n time units

I think this is a good example of the kind of new commands and abilities that
come with having a reverse ability in the first place, like Marc said. 

And as the later discussion evolved, it would be jolly nice to have an idea of
time in gdb. I think that is needed anyway to handle multicore, multiprocessor,
and multithreaded debug: when things happen in disparate locations under the
control of a single debugger quickly gets very interesting...

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47    
Drottningholmsvägen 14      Mobile: +46 709 242 646   
11243 Stockholm             Web:    www.virtutech.com  
Sweden
________________________________________________________
 

RE: reverse for GDB/MI

[Marc Khouzam]

Hi,

I am hoping this request can help restart the process
of getting the reverse MI commands approved.

I have applied the patches of Process Record and Replay
and have built myself a nice GDB that can do reverse debugging
on Linux.

I then implemented the corresponding support in DSF-GDB 
(soon to be committed.)  However, I ran into some MI limitations
(explanation below for those interested) which make me need 
the MI Commands for Reverse debugging.

A patch for these commands was submitted in
http://sourceware.org/ml/gdb-patches/2008-12/msg00276.html
but there were many discussions after, which did not seem to
conclude. 

The details of my troubles follow:

With no MI commands for Reverse I tried to use CLI commands
but ran into a bug causing incomplete MI *stopped event when using CLI commands.
http://sourceware.org/ml/gdb/2008-12/msg00058.html

As per Nick's finding, I tried Async mode to work around *stopped event bug but
realized Process Record and Replay does not support Async.

So, the solution I currently have is to use "set execution-direction" and the
MI commands for execution.  For example, to perform a 'reverse-continue' from
DSF-GDB I have to do the set of three commands:

set execution-direction reverse
-exec-continue
set execution-direction forward

It would be nice to have the reverse MI commands :-)

Thanks

Marc

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jakob Engblom
> Sent: Saturday, January 03, 2009 1:09 PM
> To: gdb-patches@sources.redhat.com
> Subject: RE: reverse for GDB/MI
> 
>  
> > Hi,
> > 
> > It was pointed out to me that people who have been doing reversible
> > debug for a while seems to
> > have specific commands for reverse debugging and they do 
> have a command
> > for "go to time point P".
> > For example http://www.undo-software.com/undodb_man.html:
> > 
> > bgoton <number>
> > Move forwards or backwards to the specified time, in simulated
> > nanoseconds.
> > bgoton +<number> | -<number>
> > Step forward/backward the specified number of simulated nanoseconds.
> 
> Simics has it to, in some different ways:
> 
> skip-to <bookmark> 
> reverse n time units
> continue n time units
> 
> I think this is a good example of the kind of new commands 
> and abilities that
> come with having a reverse ability in the first place, like 
> Marc said. 
> 
> And as the later discussion evolved, it would be jolly nice 
> to have an idea of
> time in gdb. I think that is needed anyway to handle 
> multicore, multiprocessor,
> and multithreaded debug: when things happen in disparate 
> locations under the
> control of a single debugger quickly gets very interesting...
> 
> Best regards,
> 
> /jakob
> 
> _______________________________________________________
> 
> Jakob Engblom, PhD, Technical Marketing Manager
> 
> Virtutech                   Direct: +46 8 690 07 47    
> Drottningholmsvägen 14      Mobile: +46 709 242 646   
> 11243 Stockholm             Web:    www.virtutech.com  
> Sweden
> ________________________________________________________
>  
> 
> 
> 

Re: reverse for GDB/MI

[teawater]

Thanks for the great work that your guys doing. :)

On Wed, Jan 21, 2009 at 02:19, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
> Hi,
>
> I am hoping this request can help restart the process
> of getting the reverse MI commands approved.
>
> I have applied the patches of Process Record and Replay
> and have built myself a nice GDB that can do reverse debugging
> on Linux.
>
> I then implemented the corresponding support in DSF-GDB
> (soon to be committed.)  However, I ran into some MI limitations
> (explanation below for those interested) which make me need
> the MI Commands for Reverse debugging.
>
> A patch for these commands was submitted in
> http://sourceware.org/ml/gdb-patches/2008-12/msg00276.html
> but there were many discussions after, which did not seem to
> conclude.
>
> The details of my troubles follow:
>
> With no MI commands for Reverse I tried to use CLI commands
> but ran into a bug causing incomplete MI *stopped event when using CLI commands.
> http://sourceware.org/ml/gdb/2008-12/msg00058.html
>
> As per Nick's finding, I tried Async mode to work around *stopped event bug but
> realized Process Record and Replay does not support Async.
>
> So, the solution I currently have is to use "set execution-direction" and the
> MI commands for execution.  For example, to perform a 'reverse-continue' from
> DSF-GDB I have to do the set of three commands:
>
> set execution-direction reverse
> -exec-continue
> set execution-direction forward
>
> It would be nice to have the reverse MI commands :-)
>
> Thanks
>
> Marc
>
>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org
>> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jakob Engblom
>> Sent: Saturday, January 03, 2009 1:09 PM
>> To: gdb-patches@sources.redhat.com
>> Subject: RE: reverse for GDB/MI
>>
>>
>> > Hi,
>> >
>> > It was pointed out to me that people who have been doing reversible
>> > debug for a while seems to
>> > have specific commands for reverse debugging and they do
>> have a command
>> > for "go to time point P".
>> > For example http://www.undo-software.com/undodb_man.html:
>> >
>> > bgoton <number>
>> > Move forwards or backwards to the specified time, in simulated
>> > nanoseconds.
>> > bgoton +<number> | -<number>
>> > Step forward/backward the specified number of simulated nanoseconds.
>>
>> Simics has it to, in some different ways:
>>
>> skip-to <bookmark>
>> reverse n time units
>> continue n time units
>>
>> I think this is a good example of the kind of new commands
>> and abilities that
>> come with having a reverse ability in the first place, like
>> Marc said.
>>
>> And as the later discussion evolved, it would be jolly nice
>> to have an idea of
>> time in gdb. I think that is needed anyway to handle
>> multicore, multiprocessor,
>> and multithreaded debug: when things happen in disparate
>> locations under the
>> control of a single debugger quickly gets very interesting...
>>
>> Best regards,
>>
>> /jakob
>>
>> _______________________________________________________
>>
>> Jakob Engblom, PhD, Technical Marketing Manager
>>
>> Virtutech                   Direct: +46 8 690 07 47
>> Drottningholmsvägen 14      Mobile: +46 709 242 646
>> 11243 Stockholm             Web:    www.virtutech.com
>> Sweden
>> ________________________________________________________
>>
>>
>>
>>
>

Re: reverse for GDB/MI

[Tomas Holmberg]

> A patch for these commands was submitted in
> http://sourceware.org/ml/gdb-patches/2008-12/msg00276.html
> but there were many discussions after, which did not seem to
> conclude.
Yes, the discussion kind of died :-). I would very much like to
see the reverse MI commands to be added. I also submitted command
descriptions.
http://sourceware.org/ml/gdb-patches/2008-12/msg00312.html

/tomas

RE: reverse for GDB/MI

[Vladimir Prus]

Marc Khouzam wrote:

> Hi,
> 
> I am hoping this request can help restart the process
> of getting the reverse MI commands approved.
> 
> I have applied the patches of Process Record and Replay
> and have built myself a nice GDB that can do reverse debugging
> on Linux.
> 
> I then implemented the corresponding support in DSF-GDB
> (soon to be committed.)  However, I ran into some MI limitations
> (explanation below for those interested) which make me need
> the MI Commands for Reverse debugging.
> 
> A patch for these commands was submitted in
> http://sourceware.org/ml/gdb-patches/2008-12/msg00276.html
> but there were many discussions after, which did not seem to
> conclude.
> 
> The details of my troubles follow:
> 
> With no MI commands for Reverse I tried to use CLI commands
> but ran into a bug causing incomplete MI *stopped event when using CLI commands.
> http://sourceware.org/ml/gdb/2008-12/msg00058.html

I have a patch for this, that I'll post/commit as soon as I figure out why,
exactly, it works.

- Volodya

Re: reverse for GDB/MI

[Michael Snyder]

Tomas Holmberg wrote:
>> I am not quite sure about adding new set of commands for that. Can we use
>> --reverse option, thereby not introducing new commands?
> 
> Adding a reverse option to the existing commands is possible. But I do
> not think it is a good idea. It is not always obvious what should
> happen when running a standard command in reverse. I consider the
> reverse commands as a new set commands and not a variant of the old.


That's correct.  The new commands (eg. reverse-next) account for
the differences between the standard commands and what should
happen in reverse.

However, note that (set exec-dir reverse ; next) is equivalent
to "reverse-next".  It will do the right thing.

Re: reverse for GDB/MI

[Tomas Holmberg]

Michael Snyder wrote:
> Tomas Holmberg wrote:
>>> I am not quite sure about adding new set of commands for that. Can we 
>>> use
>>> --reverse option, thereby not introducing new commands?
>>
>> Adding a reverse option to the existing commands is possible. But I do
>> not think it is a good idea. It is not always obvious what should
>> happen when running a standard command in reverse. I consider the
>> reverse commands as a new set commands and not a variant of the old.
> 
> 
> That's correct.  The new commands (eg. reverse-next) account for
> the differences between the standard commands and what should
> happen in reverse.
> 
> However, note that (set exec-dir reverse ; next) is equivalent
> to "reverse-next".  It will do the right thing.

I am not convinced that adding the exec-dir setting was good. What should
the user expect when first changing the direction to reverse and then
doing reverse-step, a normal step? GDB currently prints a warning in
this case, "Already in reverse mode...".

Why is not reverse the normal debugging direction and forward the
non-normal one? I know that debugging forward should/must be default,
I just want to open everyones mind about reverse debugging.
What is the normal debugging case? something has gone wrong and you
want to see what happened or you know that something will go wrong
and you want to see what happens.

/tomas