Reverse debugging

Reverse debugging

[Nick Roberts]

On i386, with current GDB, if I do:

  (gdb) reverse-next

I get:

  Target child does not support this command.

However if I do:

  (gdb) target record

first, and proceed, then "reverse-next" does indeed work as I would expect.

In the "Reverse Execution" node of the GDB manual it talks about
"a target environment that supports reverse execution" but doesn't clarify
what those targets are.  The node "Process Record and Replay" comes next
in the manual but these two seem to be inimately related.

Is it possible to reverse debug without doing "target record" first?  If not
then I think "Reverse Execution" should be a sub-node of "Process Record and
Replay".  In any case it would be helpful to mention "target record" in the
"Reverse Execution" node if most platforms don't support reverse execution
outside record and replay.

Is there a GDB command that shows if process recording is started/stopped?
"target record" doesn't appear to influence the output of 'info target".

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Reverse debugging

[Michael Snyder]

Nick Roberts wrote:
> On i386, with current GDB, if I do:
> 
>   (gdb) reverse-next
> 
> I get:
> 
>   Target child does not support this command.
> 
> However if I do:
> 
>   (gdb) target record
> 
> first, and proceed, then "reverse-next" does indeed work as I would expect.

That's because target exec does not support reverse,
but target record does.  Reverse is also potentially
supported under target remote, depending on what remote
target you're connected to.

> In the "Reverse Execution" node of the GDB manual it talks about
> "a target environment that supports reverse execution" but doesn't clarify
> what those targets are.  The node "Process Record and Replay" comes next
> in the manual but these two seem to be inimately related.

Process record (target record) is one of a small number of
targets that currently support reverse debugging.  The others,
so far, are all remote targets (eg. SID from Red Hat, and
Simics from Virtutech).

> Is it possible to reverse debug without doing "target record" first? 

Yes -- but not under target exec (normal native debugging).

> If not
> then I think "Reverse Execution" should be a sub-node of "Process Record and
> Replay".  In any case it would be helpful to mention "target record" in the
> "Reverse Execution" node if most platforms don't support reverse execution
> outside record and replay.

No, reverse execution is not tied to process record -- it just
isn't available under target exec.

> Is there a GDB command that shows if process recording is started/stopped?
> "target record" doesn't appear to influence the output of 'info target".

Good question.  We've been discussing the same question under
the thread "Testing of reverse debug commands", and I think
we're leaning toward the conclusion "we need such a command".

Re: Reverse debugging

[Nick Roberts]

 > That's because target exec does not support reverse,
 > but target record does.  Reverse is also potentially
 > supported under target remote, depending on what remote
 > target you're connected to.
 > 
 > > In the "Reverse Execution" node of the GDB manual it talks about
 > > "a target environment that supports reverse execution" but doesn't clarify
 > > what those targets are.  The node "Process Record and Replay" comes next
 > > in the manual but these two seem to be inimately related.
 > 
 > Process record (target record) is one of a small number of
 > targets that currently support reverse debugging.  The others,
 > so far, are all remote targets (eg. SID from Red Hat, and
 > Simics from Virtutech).
 >...

Thanks for these answers, I find them more lucid than the manual.  If I try
to reverse a remote target using gdbserver (actually on host/local machine -
x86_64 this time), I'm not told that the target doesn't support this command
but reverse-next works just like next until I hit a function:

(gdb) reverse-next

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000400521 in printf@plt ()
Current language:  auto; currently asm
(gdb) 

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Reverse debugging

[Michael Snyder]

Nick Roberts wrote:
>  > That's because target exec does not support reverse,
>  > but target record does.  Reverse is also potentially
>  > supported under target remote, depending on what remote
>  > target you're connected to.
>  > 
>  > > In the "Reverse Execution" node of the GDB manual it talks about
>  > > "a target environment that supports reverse execution" but doesn't clarify
>  > > what those targets are.  The node "Process Record and Replay" comes next
>  > > in the manual but these two seem to be inimately related.
>  > 
>  > Process record (target record) is one of a small number of
>  > targets that currently support reverse debugging.  The others,
>  > so far, are all remote targets (eg. SID from Red Hat, and
>  > Simics from Virtutech).
>  >...
> 
> Thanks for these answers, I find them more lucid than the manual.  If I try
> to reverse a remote target using gdbserver (actually on host/local machine -
> x86_64 this time), I'm not told that the target doesn't support this command
> but reverse-next works just like next until I hit a function:
> 
> (gdb) reverse-next
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000000000400521 in printf@plt ()
> Current language:  auto; currently asm
> (gdb) 
> 

Sounds like you are using "record" on top of "target remote"?

I wasn't sure if that would work or not, but sounds like it does.

The failure you are seeing is one that I have an outstanding
change ready to fix.

Re: Reverse debugging

[Nick Roberts]

I've created tool bar functionality in Emacs for reverse debugging a bit like
that in the DSF-GDB debugger for Eclipse, I think.

It works quite nicely and I would like to include it in Emacs 23.2 (23.1
should be coming out next week) but there is one small problem with "record
stop".  It currently prompts the user for confirmation and Emacs can't handle
that from the tool bar and update the GUI.  Would it be possible to add a
"noconfirm" option, perhaps like below, which should be invisible to the
normal user?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2009-07-15  Nick Roberts  <nickrob@snap.net.nz>

	* record.c (cmd_record_stop): Add a "noconfirm" option to the
	"record stop" command.


Index: record.c
===================================================================
RCS file: /cvs/src/src/gdb/record.c,v
retrieving revision 1.8
diff -c -p -r1.8 record.c
*** record.c	2 Jul 2009 17:21:06 -0000	1.8
--- record.c	15 Jul 2009 02:25:21 -0000
*************** cmd_record_stop (char *args, int from_tt
*** 1157,1164 ****
  {
    if (current_target.to_stratum == record_stratum)
      {
!       if (!record_list || !from_tty || query (_("Delete recorded log and "
! 	                                        "stop recording?")))
  	unpush_target (&record_ops);
      }
    else
--- 1157,1168 ----
  {
    if (current_target.to_stratum == record_stratum)
      {
!       int noconfirm = 0;
!       if (args)
!         noconfirm = (strcmp (args, "noconfirm") == 0) ? 1 : 0;
! 	
!       if (!record_list || !from_tty || noconfirm
! 	  || query (_("Delete recorded log and stop recording?")))
  	unpush_target (&record_ops);
      }
    else

Re: Reverse debugging

[Hui Zhu]

Thanks Nick,  I think the better way is add a special cmd for it.

Marc, do you have some ideas with it?


Thanks,
Hui

On Wed, Jul 15, 2009 at 10:27, Nick Roberts<nickrob@snap.net.nz> wrote:
> I've created tool bar functionality in Emacs for reverse debugging a bit like
> that in the DSF-GDB debugger for Eclipse, I think.
>
> It works quite nicely and I would like to include it in Emacs 23.2 (23.1
> should be coming out next week) but there is one small problem with "record
> stop".  It currently prompts the user for confirmation and Emacs can't handle
> that from the tool bar and update the GUI.  Would it be possible to add a
> "noconfirm" option, perhaps like below, which should be invisible to the
> normal user?
>
> --
> Nick                                           http://www.inet.net.nz/~nickrob
>
>
> 2009-07-15  Nick Roberts  <nickrob@snap.net.nz>
>
>        * record.c (cmd_record_stop): Add a "noconfirm" option to the
>        "record stop" command.
>
>
> Index: record.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/record.c,v
> retrieving revision 1.8
> diff -c -p -r1.8 record.c
> *** record.c    2 Jul 2009 17:21:06 -0000       1.8
> --- record.c    15 Jul 2009 02:25:21 -0000
> *************** cmd_record_stop (char *args, int from_tt
> *** 1157,1164 ****
>  {
>    if (current_target.to_stratum == record_stratum)
>      {
> !       if (!record_list || !from_tty || query (_("Delete recorded log and "
> !                                               "stop recording?")))
>        unpush_target (&record_ops);
>      }
>    else
> --- 1157,1168 ----
>  {
>    if (current_target.to_stratum == record_stratum)
>      {
> !       int noconfirm = 0;
> !       if (args)
> !         noconfirm = (strcmp (args, "noconfirm") == 0) ? 1 : 0;
> !
> !       if (!record_list || !from_tty || noconfirm
> !         || query (_("Delete recorded log and stop recording?")))
>        unpush_target (&record_ops);
>      }
>    else
>

RE: Reverse debugging

[Marc Khouzam]

> -----Original Message-----
> From: Hui Zhu [mailto:teawater@gmail.com] 
> Sent: July-15-09 11:09 PM
> To: Nick Roberts; Marc Khouzam
> Cc: gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
> 
> Thanks Nick,  I think the better way is add a special cmd for it.
> 
> Marc, do you have some ideas with it?
> 
> 
> Thanks,
> Hui
> 
> On Wed, Jul 15, 2009 at 10:27, Nick 
> Roberts<nickrob@snap.net.nz> wrote:
> > I've created tool bar functionality in Emacs for reverse 
> debugging a bit like
> > that in the DSF-GDB debugger for Eclipse, I think.

Cool!

> >
> > It works quite nicely and I would like to include it in 
> Emacs 23.2 (23.1
> > should be coming out next week) but there is one small 
> problem with "record
> > stop".  It currently prompts the user for confirmation and 
> Emacs can't handle
> > that from the tool bar and update the GUI.  Would it be 
> possible to add a
> > "noconfirm" option, perhaps like below, which should be 
> invisible to the
> > normal user?

So in your case you are dealing with a proper tty?
For eclipse, we fall in the !from_tty case.

Frontends should definetely not be bothered with those queries.
In my mind, a FE should know what it is doing so if it requests
an action like 'record stop' it should not be prompted at all.
This is probably true for any of these queries.

I was originally going to ask Hui always have a !from_tty check,
but now it seems this would not work for emacs.

Can we check if the default interpreter is MI somehow and in those
cases not do the query?  The idea is that if one uses MI then
it is not in some user-interactive session.

Just a thought...

Marc


> >
> > --
> > Nick                                           
> http://www.inet.net.nz/~nickrob
> >
> >
> > 2009-07-15  Nick Roberts  <nickrob@snap.net.nz>
> >
> >        * record.c (cmd_record_stop): Add a "noconfirm" option to the
> >        "record stop" command.
> >
> >
> > Index: record.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/record.c,v
> > retrieving revision 1.8
> > diff -c -p -r1.8 record.c
> > *** record.c    2 Jul 2009 17:21:06 -0000       1.8
> > --- record.c    15 Jul 2009 02:25:21 -0000
> > *************** cmd_record_stop (char *args, int from_tt
> > *** 1157,1164 ****
> >  {
> >    if (current_target.to_stratum == record_stratum)
> >      {
> > !       if (!record_list || !from_tty || query (_("Delete 
> recorded log and "
> > !                                               "stop recording?")))
> >        unpush_target (&record_ops);
> >      }
> >    else
> > --- 1157,1168 ----
> >  {
> >    if (current_target.to_stratum == record_stratum)
> >      {
> > !       int noconfirm = 0;
> > !       if (args)
> > !         noconfirm = (strcmp (args, "noconfirm") == 0) ? 1 : 0;
> > !
> > !       if (!record_list || !from_tty || noconfirm
> > !         || query (_("Delete recorded log and stop recording?")))
> >        unpush_target (&record_ops);
> >      }
> >    else
> >
> 

RE: Reverse debugging

[Nick Roberts]

 > So in your case you are dealing with a proper tty?
 > For eclipse, we fall in the !from_tty case.

Emacs communicates with GDB through a pseudo-tty.  How does Eclipse
do it?

This also seems contrary to what Daniel Jacobowitz has previously told me,
perhaps about Eclipse more generally.  CDT has a console and I thought he
assured me that there was interest in developing that functionality.

 > Frontends should definetely not be bothered with those queries.
 > In my mind, a FE should know what it is doing so if it requests
 > an action like 'record stop' it should not be prompted at all.
 > This is probably true for any of these queries.
 > 
 > I was originally going to ask Hui always have a !from_tty check,
 > but now it seems this would not work for emacs.
 > 
 > Can we check if the default interpreter is MI somehow and in those
 > cases not do the query?  The idea is that if one uses MI then
 > it is not in some user-interactive session.
 > 
 > Just a thought...

That might be a good idea but this request isn't for Emacs on trunk, which has
now migrated fully to GDB/MI, but for the release branch which still uses
annotations.  It's just a small request for a slight change to the existing
command "record stop" or, as Hui suggested, adding a special CLI command
to stop recording that doesn't need confirmation.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: Reverse debugging

[Marc Khouzam]

> -----Original Message-----
> From: Nick Roberts [mailto:nickrob@snap.net.nz] 
> Sent: July-16-09 10:42 PM
> To: Marc Khouzam
> Cc: Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> Subject: RE: Reverse debugging
> 
>  > So in your case you are dealing with a proper tty?
>  > For eclipse, we fall in the !from_tty case.
> 
> Emacs communicates with GDB through a pseudo-tty.  How does Eclipse
> do it?
> 
> This also seems contrary to what Daniel Jacobowitz has 
> previously told me,
> perhaps about Eclipse more generally.  CDT has a console and 
> I thought he
> assured me that there was interest in developing that functionality.

We do have a console and we do want it to be fully supported :-)
But all commands sent from the console are redirected through
our normal MI channel and I think this is the reason we
are not a tty in that case.

For example when turning off record from that console or from
the eclipse buttons I get: 
"Delete recorded log and stop recording?(y or n) [answered Y; input not
from terminal]"

I noticed that the previous CDT GDB integration has its console
considered
a tty.  It may be worth looking into the difference... when time allows
it :-)

> 
>  > Frontends should definetely not be bothered with those queries.
>  > In my mind, a FE should know what it is doing so if it requests
>  > an action like 'record stop' it should not be prompted at all.
>  > This is probably true for any of these queries.
>  > 
>  > I was originally going to ask Hui always have a !from_tty check,
>  > but now it seems this would not work for emacs.
>  > 
>  > Can we check if the default interpreter is MI somehow and in those
>  > cases not do the query?  The idea is that if one uses MI then
>  > it is not in some user-interactive session.
>  > 
>  > Just a thought...
> 
> That might be a good idea but this request isn't for Emacs on 
> trunk, which has
> now migrated fully to GDB/MI, but for the release branch 
> which still uses
> annotations.  

So you start GDB in CLI mode?
My idea was that if gdb is started with '-interpreter mi', we could
assume it is a frontend that started it and not use queries.

> It's just a small request for a slight change 
> to the existing
> command "record stop" or, as Hui suggested, adding a special 
> CLI command
> to stop recording that doesn't need confirmation.

I have nothing against that.  How about making this command MI?

Marc

Re: Reverse debugging

[Daniel Jacobowitz]

On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> I noticed that the previous CDT GDB integration has its console
> considered
> a tty.  It may be worth looking into the difference... when time allows
> it :-)

Wasn't someone just talking on cdt-dev about trouble with whether DSF
used Spawner or not?  That'd do it.

> So you start GDB in CLI mode?
> My idea was that if gdb is started with '-interpreter mi', we could
> assume it is a frontend that started it and not use queries.

How about checking the current interpreter in query, instead?

-- 
Daniel Jacobowitz
CodeSourcery

RE: Reverse debugging

[Marc Khouzam]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org] 
> Sent: July-17-09 10:25 AM
> To: Marc Khouzam
> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
> 
> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> > I noticed that the previous CDT GDB integration has its console
> > considered
> > a tty.  It may be worth looking into the difference... when 
> time allows
> > it :-)
> 
> Wasn't someone just talking on cdt-dev about trouble with whether DSF
> used Spawner or not?  That'd do it.

Thanks for the pointer, I'll have to look into it.

 
> > So you start GDB in CLI mode?
> > My idea was that if gdb is started with '-interpreter mi', we could
> > assume it is a frontend that started it and not use queries.
> 
> How about checking the current interpreter in query, instead?

That would be for the current command only?
That is a better solution.  However, 'record' et al. don't have 
MI equivalents.  But I could use '-interpreter-exec console record'
if that would make your suggestion work.

Marc

Re: Reverse debugging

[Daniel Jacobowitz]

On Fri, Jul 17, 2009 at 10:55:05AM -0400, Marc Khouzam wrote:
> > > So you start GDB in CLI mode?
> > > My idea was that if gdb is started with '-interpreter mi', we could
> > > assume it is a frontend that started it and not use queries.
> > 
> > How about checking the current interpreter in query, instead?
> 
> That would be for the current command only?
> That is a better solution.  However, 'record' et al. don't have 
> MI equivalents.  But I could use '-interpreter-exec console record'
> if that would make your suggestion work.

Guess you need top_level_interpreter then.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Reverse debugging

[Marc Khouzam]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org] 
> Sent: July-17-09 10:25 AM
> To: Marc Khouzam
> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
> 
> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> > I noticed that the previous CDT GDB integration has its console
> > considered
> > a tty.  It may be worth looking into the difference... when 
> time allows
> > it :-)
> 
> Wasn't someone just talking on cdt-dev about trouble with whether DSF
> used Spawner or not?  That'd do it.

I was wrong about the console being a tty.  The old CDT GDB integration
console is also not a tty.  What they do though is use
'set confirm off'.  That makes sense since queries are being answered
automatically anyway.

Nick, in your specific case 'confirm off' would work.  The default
answer to
'record stop' is yes (well, there is not default, but in that case, 'y'
is
chosen).  If you don't want to always 'set confirm off' you may consider
setting it right before sending 'record stop' and turn it back on
right after.  That may be a good enough workaround until there is a
proper
solution to this query problem.

For me the problem for PRecord remains because the default value is 
not always what I want.  For example, in PRecord the default answer 
to changing memory and loosing the recorded history
is "N", but as a frontend, I want to answer "Y".

To fix this problem I suggest that in record.c, 
we replace 'nquery' with 'query'; that will make the default be 'Y' when

confirm is off or when there is no tty.  Note that this seems to be what

is being done everywhere else in GDB.  There is only one case (pending 
breakpoints) that uses default queries, outside of PRecord.  Except for
that 
one case, it is really only PRecord that uses yquery and nquery.  And
the 
pending breakpoint case is not a problem for frontends that use MI
because
the MI command does not trigger the query.

Note that up to now, I've been recompiling GDB with that suggestion
so that I can properly use PRecord in Eclipse.

The below patch implements the suggestion.

Thanks

Marc

ChangeLog
2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>

	* record.c (record_store_registers): Replace nquery with 
	query to allow frontends to automatically answer 'y'.
	(record_xfer_partial): Ditto.


### Eclipse Workspace Patch 1.0
#P src
Index: gdb/record.c
===================================================================
RCS file: /cvs/src/src/gdb/record.c,v
retrieving revision 1.8
diff -u -r1.8 record.c
--- gdb/record.c	2 Jul 2009 17:21:06 -0000	1.8
+++ gdb/record.c	19 Jul 2009 03:06:01 -0000
@@ -937,13 +937,13 @@
 	  /* Let user choose if he wants to write register or not.  */
 	  if (regno < 0)
 	    n =
-	      nquery (_("Because GDB is in replay mode, changing the "
+	      query (_("Because GDB is in replay mode, changing the "
 			"value of a register will make the execution "
 			"log unusable from this point onward.  "
 			"Change all registers?"));
 	  else
 	    n =
-	      nquery (_("Because GDB is in replay mode, changing the
value "
+	      query (_("Because GDB is in replay mode, changing the
value "
 			"of a register will make the execution log
unusable "
 			"from this point onward.  Change register %s?"),
 		      gdbarch_register_name (get_regcache_arch
(regcache),
@@ -993,7 +993,7 @@
       if (RECORD_IS_REPLAY)
 	{
 	  /* Let user choose if he wants to write memory or not.  */
-	  if (!nquery (_("Because GDB is in replay mode, writing to
memory "
+	  if (!query (_("Because GDB is in replay mode, writing to
memory "
 		         "will make the execution log unusable from this
"
 		         "point onward.  Write memory at address %s?"),
 		       paddress (target_gdbarch, offset)))

Re: Reverse debugging

[Hui Zhu]

Thanks Marc,  but what about I keep it but add some switches for it?
I want keep the query to tui user.
For example:
set record query off
set record changememeory on

Thanks,
Hui


On Sun, Jul 19, 2009 at 11:19, Marc Khouzam<marc.khouzam@ericsson.com> wrote:
>> -----Original Message-----
>> From: Daniel Jacobowitz [mailto:drow@false.org]
>> Sent: July-17-09 10:25 AM
>> To: Marc Khouzam
>> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
>> Subject: Re: Reverse debugging
>>
>> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
>> > I noticed that the previous CDT GDB integration has its console
>> > considered
>> > a tty.  It may be worth looking into the difference... when
>> time allows
>> > it :-)
>>
>> Wasn't someone just talking on cdt-dev about trouble with whether DSF
>> used Spawner or not?  That'd do it.
>
> I was wrong about the console being a tty.  The old CDT GDB integration
> console is also not a tty.  What they do though is use
> 'set confirm off'.  That makes sense since queries are being answered
> automatically anyway.
>
> Nick, in your specific case 'confirm off' would work.  The default
> answer to
> 'record stop' is yes (well, there is not default, but in that case, 'y'
> is
> chosen).  If you don't want to always 'set confirm off' you may consider
> setting it right before sending 'record stop' and turn it back on
> right after.  That may be a good enough workaround until there is a
> proper
> solution to this query problem.
>
> For me the problem for PRecord remains because the default value is
> not always what I want.  For example, in PRecord the default answer
> to changing memory and loosing the recorded history
> is "N", but as a frontend, I want to answer "Y".
>
> To fix this problem I suggest that in record.c,
> we replace 'nquery' with 'query'; that will make the default be 'Y' when
>
> confirm is off or when there is no tty.  Note that this seems to be what
>
> is being done everywhere else in GDB.  There is only one case (pending
> breakpoints) that uses default queries, outside of PRecord.  Except for
> that
> one case, it is really only PRecord that uses yquery and nquery.  And
> the
> pending breakpoint case is not a problem for frontends that use MI
> because
> the MI command does not trigger the query.
>
> Note that up to now, I've been recompiling GDB with that suggestion
> so that I can properly use PRecord in Eclipse.
>
> The below patch implements the suggestion.
>
> Thanks
>
> Marc
>
> ChangeLog
> 2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>
>
>        * record.c (record_store_registers): Replace nquery with
>        query to allow frontends to automatically answer 'y'.
>        (record_xfer_partial): Ditto.
>
>
> ### Eclipse Workspace Patch 1.0
> #P src
> Index: gdb/record.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/record.c,v
> retrieving revision 1.8
> diff -u -r1.8 record.c
> --- gdb/record.c        2 Jul 2009 17:21:06 -0000       1.8
> +++ gdb/record.c        19 Jul 2009 03:06:01 -0000
> @@ -937,13 +937,13 @@
>          /* Let user choose if he wants to write register or not.  */
>          if (regno < 0)
>            n =
> -             nquery (_("Because GDB is in replay mode, changing the "
> +             query (_("Because GDB is in replay mode, changing the "
>                        "value of a register will make the execution "
>                        "log unusable from this point onward.  "
>                        "Change all registers?"));
>          else
>            n =
> -             nquery (_("Because GDB is in replay mode, changing the
> value "
> +             query (_("Because GDB is in replay mode, changing the
> value "
>                        "of a register will make the execution log
> unusable "
>                        "from this point onward.  Change register %s?"),
>                      gdbarch_register_name (get_regcache_arch
> (regcache),
> @@ -993,7 +993,7 @@
>       if (RECORD_IS_REPLAY)
>        {
>          /* Let user choose if he wants to write memory or not.  */
> -         if (!nquery (_("Because GDB is in replay mode, writing to
> memory "
> +         if (!query (_("Because GDB is in replay mode, writing to
> memory "
>                         "will make the execution log unusable from this
> "
>                         "point onward.  Write memory at address %s?"),
>                       paddress (target_gdbarch, offset)))
>
>
>
>

RE: Reverse debugging

[Marc Khouzam]

 

> -----Original Message-----
> From: Hui Zhu [mailto:teawater@gmail.com] 
> Sent: Sunday, July 19, 2009 11:27 PM
> To: Marc Khouzam; Nick Roberts
> Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
> 
> Thanks Marc,  but what about I keep it but add some switches for it?
> I want keep the query to tui user.
> For example:
> set record query off
> set record changememeory on

(Note that I'm only suggesting to not make the query default to 'Y'.
There would still be a query though.)

I've been giving the whole problem a little more thought, and I now
think that it is the way queries are answered that should be changed
generically.

I'll post a patch today and see what people think.

Note that the suggestion I will post will rely on 'set confirm off'.
If Nick cannot use that then he'll still need you to have a switch to
turn these queries off.

Thanks

Marc


> 
> Thanks,
> Hui
> 
> 
> On Sun, Jul 19, 2009 at 11:19, Marc 
> Khouzam<marc.khouzam@ericsson.com> wrote:
> >> -----Original Message-----
> >> From: Daniel Jacobowitz [mailto:drow@false.org]
> >> Sent: July-17-09 10:25 AM
> >> To: Marc Khouzam
> >> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> >> Subject: Re: Reverse debugging
> >>
> >> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> >> > I noticed that the previous CDT GDB integration has its console
> >> > considered
> >> > a tty.  It may be worth looking into the difference... when
> >> time allows
> >> > it :-)
> >>
> >> Wasn't someone just talking on cdt-dev about trouble with 
> whether DSF
> >> used Spawner or not?  That'd do it.
> >
> > I was wrong about the console being a tty.  The old CDT GDB 
> integration
> > console is also not a tty.  What they do though is use
> > 'set confirm off'.  That makes sense since queries are 
> being answered
> > automatically anyway.
> >
> > Nick, in your specific case 'confirm off' would work.  The default
> > answer to
> > 'record stop' is yes (well, there is not default, but in 
> that case, 'y'
> > is
> > chosen).  If you don't want to always 'set confirm off' you 
> may consider
> > setting it right before sending 'record stop' and turn it back on
> > right after.  That may be a good enough workaround until there is a
> > proper
> > solution to this query problem.
> >
> > For me the problem for PRecord remains because the default value is
> > not always what I want.  For example, in PRecord the default answer
> > to changing memory and loosing the recorded history
> > is "N", but as a frontend, I want to answer "Y".
> >
> > To fix this problem I suggest that in record.c,
> > we replace 'nquery' with 'query'; that will make the 
> default be 'Y' when
> >
> > confirm is off or when there is no tty.  Note that this 
> seems to be what
> >
> > is being done everywhere else in GDB.  There is only one 
> case (pending
> > breakpoints) that uses default queries, outside of PRecord. 
>  Except for
> > that
> > one case, it is really only PRecord that uses yquery and 
> nquery.  And
> > the
> > pending breakpoint case is not a problem for frontends that use MI
> > because
> > the MI command does not trigger the query.
> >
> > Note that up to now, I've been recompiling GDB with that suggestion
> > so that I can properly use PRecord in Eclipse.
> >
> > The below patch implements the suggestion.
> >
> > Thanks
> >
> > Marc
> >
> > ChangeLog
> > 2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>
> >
> >        * record.c (record_store_registers): Replace nquery with
> >        query to allow frontends to automatically answer 'y'.
> >        (record_xfer_partial): Ditto.
> >
> >
> > ### Eclipse Workspace Patch 1.0
> > #P src
> > Index: gdb/record.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/record.c,v
> > retrieving revision 1.8
> > diff -u -r1.8 record.c
> > --- gdb/record.c        2 Jul 2009 17:21:06 -0000       1.8
> > +++ gdb/record.c        19 Jul 2009 03:06:01 -0000
> > @@ -937,13 +937,13 @@
> >          /* Let user choose if he wants to write register 
> or not.  */
> >          if (regno < 0)
> >            n =
> > -             nquery (_("Because GDB is in replay mode, 
> changing the "
> > +             query (_("Because GDB is in replay mode, 
> changing the "
> >                        "value of a register will make the 
> execution "
> >                        "log unusable from this point onward.  "
> >                        "Change all registers?"));
> >          else
> >            n =
> > -             nquery (_("Because GDB is in replay mode, changing the
> > value "
> > +             query (_("Because GDB is in replay mode, changing the
> > value "
> >                        "of a register will make the execution log
> > unusable "
> >                        "from this point onward.  Change 
> register %s?"),
> >                      gdbarch_register_name (get_regcache_arch
> > (regcache),
> > @@ -993,7 +993,7 @@
> >       if (RECORD_IS_REPLAY)
> >        {
> >          /* Let user choose if he wants to write memory or not.  */
> > -         if (!nquery (_("Because GDB is in replay mode, writing to
> > memory "
> > +         if (!query (_("Because GDB is in replay mode, writing to
> > memory "
> >                         "will make the execution log 
> unusable from this
> > "
> >                         "point onward.  Write memory at 
> address %s?"),
> >                       paddress (target_gdbarch, offset)))
> >
> >
> >
> >
> 

RE: Reverse debugging

[Marc Khouzam]

Typo in my previous email.  Sorry.

> (Note that I'm only suggesting to not make the query default to 'Y'.
> There would still be a query though.)

Should have read (no "not")

> (Note that I'm only suggesting to make the query default to 'Y'.
> There would still be a query though.)

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Marc Khouzam
> Sent: Monday, July 20, 2009 8:50 AM
> To: Hui Zhu; Nick Roberts
> Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
> Subject: RE: Reverse debugging
> 
>  
> 
> > -----Original Message-----
> > From: Hui Zhu [mailto:teawater@gmail.com] 
> > Sent: Sunday, July 19, 2009 11:27 PM
> > To: Marc Khouzam; Nick Roberts
> > Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
> > Subject: Re: Reverse debugging
> > 
> > Thanks Marc,  but what about I keep it but add some switches for it?
> > I want keep the query to tui user.
> > For example:
> > set record query off
> > set record changememeory on
> 
> (Note that I'm only suggesting to make the query default to 'Y'.
> There would still be a query though.)
> 
> I've been giving the whole problem a little more thought, and I now
> think that it is the way queries are answered that should be changed
> generically.
> 
> I'll post a patch today and see what people think.
> 
> Note that the suggestion I will post will rely on 'set confirm off'.
> If Nick cannot use that then he'll still need you to have a switch to
> turn these queries off.
> 
> Thanks
> 
> Marc
> 
> 
> > 
> > Thanks,
> > Hui
> > 
> > 
> > On Sun, Jul 19, 2009 at 11:19, Marc 
> > Khouzam<marc.khouzam@ericsson.com> wrote:
> > >> -----Original Message-----
> > >> From: Daniel Jacobowitz [mailto:drow@false.org]
> > >> Sent: July-17-09 10:25 AM
> > >> To: Marc Khouzam
> > >> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> > >> Subject: Re: Reverse debugging
> > >>
> > >> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> > >> > I noticed that the previous CDT GDB integration has its console
> > >> > considered
> > >> > a tty.  It may be worth looking into the difference... when
> > >> time allows
> > >> > it :-)
> > >>
> > >> Wasn't someone just talking on cdt-dev about trouble with 
> > whether DSF
> > >> used Spawner or not?  That'd do it.
> > >
> > > I was wrong about the console being a tty.  The old CDT GDB 
> > integration
> > > console is also not a tty.  What they do though is use
> > > 'set confirm off'.  That makes sense since queries are 
> > being answered
> > > automatically anyway.
> > >
> > > Nick, in your specific case 'confirm off' would work.  The default
> > > answer to
> > > 'record stop' is yes (well, there is not default, but in 
> > that case, 'y'
> > > is
> > > chosen).  If you don't want to always 'set confirm off' you 
> > may consider
> > > setting it right before sending 'record stop' and turn it back on
> > > right after.  That may be a good enough workaround until 
> there is a
> > > proper
> > > solution to this query problem.
> > >
> > > For me the problem for PRecord remains because the 
> default value is
> > > not always what I want.  For example, in PRecord the 
> default answer
> > > to changing memory and loosing the recorded history
> > > is "N", but as a frontend, I want to answer "Y".
> > >
> > > To fix this problem I suggest that in record.c,
> > > we replace 'nquery' with 'query'; that will make the 
> > default be 'Y' when
> > >
> > > confirm is off or when there is no tty.  Note that this 
> > seems to be what
> > >
> > > is being done everywhere else in GDB.  There is only one 
> > case (pending
> > > breakpoints) that uses default queries, outside of PRecord. 
> >  Except for
> > > that
> > > one case, it is really only PRecord that uses yquery and 
> > nquery.  And
> > > the
> > > pending breakpoint case is not a problem for frontends that use MI
> > > because
> > > the MI command does not trigger the query.
> > >
> > > Note that up to now, I've been recompiling GDB with that 
> suggestion
> > > so that I can properly use PRecord in Eclipse.
> > >
> > > The below patch implements the suggestion.
> > >
> > > Thanks
> > >
> > > Marc
> > >
> > > ChangeLog
> > > 2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>
> > >
> > >        * record.c (record_store_registers): Replace nquery with
> > >        query to allow frontends to automatically answer 'y'.
> > >        (record_xfer_partial): Ditto.
> > >
> > >
> > > ### Eclipse Workspace Patch 1.0
> > > #P src
> > > Index: gdb/record.c
> > > 
> ===================================================================
> > > RCS file: /cvs/src/src/gdb/record.c,v
> > > retrieving revision 1.8
> > > diff -u -r1.8 record.c
> > > --- gdb/record.c        2 Jul 2009 17:21:06 -0000       1.8
> > > +++ gdb/record.c        19 Jul 2009 03:06:01 -0000
> > > @@ -937,13 +937,13 @@
> > >          /* Let user choose if he wants to write register 
> > or not.  */
> > >          if (regno < 0)
> > >            n =
> > > -             nquery (_("Because GDB is in replay mode, 
> > changing the "
> > > +             query (_("Because GDB is in replay mode, 
> > changing the "
> > >                        "value of a register will make the 
> > execution "
> > >                        "log unusable from this point onward.  "
> > >                        "Change all registers?"));
> > >          else
> > >            n =
> > > -             nquery (_("Because GDB is in replay mode, 
> changing the
> > > value "
> > > +             query (_("Because GDB is in replay mode, 
> changing the
> > > value "
> > >                        "of a register will make the execution log
> > > unusable "
> > >                        "from this point onward.  Change 
> > register %s?"),
> > >                      gdbarch_register_name (get_regcache_arch
> > > (regcache),
> > > @@ -993,7 +993,7 @@
> > >       if (RECORD_IS_REPLAY)
> > >        {
> > >          /* Let user choose if he wants to write memory 
> or not.  */
> > > -         if (!nquery (_("Because GDB is in replay mode, 
> writing to
> > > memory "
> > > +         if (!query (_("Because GDB is in replay mode, writing to
> > > memory "
> > >                         "will make the execution log 
> > unusable from this
> > > "
> > >                         "point onward.  Write memory at 
> > address %s?"),
> > >                       paddress (target_gdbarch, offset)))
> > >
> > >
> > >
> > >
> > 
> 

Re: Reverse debugging

[Hui Zhu]

Hi Marc,

About change nquery to yquery,  if the user answer y, a lot of record
entry will be delete.  So I think nquery to be default is better.

Your patch change yquery to query is OK with me.

In prec, I use a lot of yquery and nquery and looks like mi cannot
control query very well.  So I think add some switches to let you can
control prec more better.

On the other hand, shell we do some work to make mi support query better?

Thanks,
Hui

On Mon, Jul 20, 2009 at 21:19, Marc Khouzam<marc.khouzam@ericsson.com> wrote:
> Typo in my previous email.  Sorry.
>
>> (Note that I'm only suggesting to not make the query default to 'Y'.
>> There would still be a query though.)
>
> Should have read (no "not")
>
>> (Note that I'm only suggesting to make the query default to 'Y'.
>> There would still be a query though.)
>
>> -----Original Message-----
>> From: gdb-owner@sourceware.org
>> [mailto:gdb-owner@sourceware.org] On Behalf Of Marc Khouzam
>> Sent: Monday, July 20, 2009 8:50 AM
>> To: Hui Zhu; Nick Roberts
>> Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
>> Subject: RE: Reverse debugging
>>
>>
>>
>> > -----Original Message-----
>> > From: Hui Zhu [mailto:teawater@gmail.com]
>> > Sent: Sunday, July 19, 2009 11:27 PM
>> > To: Marc Khouzam; Nick Roberts
>> > Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
>> > Subject: Re: Reverse debugging
>> >
>> > Thanks Marc,  but what about I keep it but add some switches for it?
>> > I want keep the query to tui user.
>> > For example:
>> > set record query off
>> > set record changememeory on
>>
>> (Note that I'm only suggesting to make the query default to 'Y'.
>> There would still be a query though.)
>>
>> I've been giving the whole problem a little more thought, and I now
>> think that it is the way queries are answered that should be changed
>> generically.
>>
>> I'll post a patch today and see what people think.
>>
>> Note that the suggestion I will post will rely on 'set confirm off'.
>> If Nick cannot use that then he'll still need you to have a switch to
>> turn these queries off.
>>
>> Thanks
>>
>> Marc
>>
>>
>> >
>> > Thanks,
>> > Hui
>> >
>> >
>> > On Sun, Jul 19, 2009 at 11:19, Marc
>> > Khouzam<marc.khouzam@ericsson.com> wrote:
>> > >> -----Original Message-----
>> > >> From: Daniel Jacobowitz [mailto:drow@false.org]
>> > >> Sent: July-17-09 10:25 AM
>> > >> To: Marc Khouzam
>> > >> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
>> > >> Subject: Re: Reverse debugging
>> > >>
>> > >> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
>> > >> > I noticed that the previous CDT GDB integration has its console
>> > >> > considered
>> > >> > a tty.  It may be worth looking into the difference... when
>> > >> time allows
>> > >> > it :-)
>> > >>
>> > >> Wasn't someone just talking on cdt-dev about trouble with
>> > whether DSF
>> > >> used Spawner or not?  That'd do it.
>> > >
>> > > I was wrong about the console being a tty.  The old CDT GDB
>> > integration
>> > > console is also not a tty.  What they do though is use
>> > > 'set confirm off'.  That makes sense since queries are
>> > being answered
>> > > automatically anyway.
>> > >
>> > > Nick, in your specific case 'confirm off' would work.  The default
>> > > answer to
>> > > 'record stop' is yes (well, there is not default, but in
>> > that case, 'y'
>> > > is
>> > > chosen).  If you don't want to always 'set confirm off' you
>> > may consider
>> > > setting it right before sending 'record stop' and turn it back on
>> > > right after.  That may be a good enough workaround until
>> there is a
>> > > proper
>> > > solution to this query problem.
>> > >
>> > > For me the problem for PRecord remains because the
>> default value is
>> > > not always what I want.  For example, in PRecord the
>> default answer
>> > > to changing memory and loosing the recorded history
>> > > is "N", but as a frontend, I want to answer "Y".
>> > >
>> > > To fix this problem I suggest that in record.c,
>> > > we replace 'nquery' with 'query'; that will make the
>> > default be 'Y' when
>> > >
>> > > confirm is off or when there is no tty.  Note that this
>> > seems to be what
>> > >
>> > > is being done everywhere else in GDB.  There is only one
>> > case (pending
>> > > breakpoints) that uses default queries, outside of PRecord.
>> >  Except for
>> > > that
>> > > one case, it is really only PRecord that uses yquery and
>> > nquery.  And
>> > > the
>> > > pending breakpoint case is not a problem for frontends that use MI
>> > > because
>> > > the MI command does not trigger the query.
>> > >
>> > > Note that up to now, I've been recompiling GDB with that
>> suggestion
>> > > so that I can properly use PRecord in Eclipse.
>> > >
>> > > The below patch implements the suggestion.
>> > >
>> > > Thanks
>> > >
>> > > Marc
>> > >
>> > > ChangeLog
>> > > 2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>
>> > >
>> > >        * record.c (record_store_registers): Replace nquery with
>> > >        query to allow frontends to automatically answer 'y'.
>> > >        (record_xfer_partial): Ditto.
>> > >
>> > >
>> > > ### Eclipse Workspace Patch 1.0
>> > > #P src
>> > > Index: gdb/record.c
>> > >
>> ===================================================================
>> > > RCS file: /cvs/src/src/gdb/record.c,v
>> > > retrieving revision 1.8
>> > > diff -u -r1.8 record.c
>> > > --- gdb/record.c        2 Jul 2009 17:21:06 -0000       1.8
>> > > +++ gdb/record.c        19 Jul 2009 03:06:01 -0000
>> > > @@ -937,13 +937,13 @@
>> > >          /* Let user choose if he wants to write register
>> > or not.  */
>> > >          if (regno < 0)
>> > >            n =
>> > > -             nquery (_("Because GDB is in replay mode,
>> > changing the "
>> > > +             query (_("Because GDB is in replay mode,
>> > changing the "
>> > >                        "value of a register will make the
>> > execution "
>> > >                        "log unusable from this point onward.  "
>> > >                        "Change all registers?"));
>> > >          else
>> > >            n =
>> > > -             nquery (_("Because GDB is in replay mode,
>> changing the
>> > > value "
>> > > +             query (_("Because GDB is in replay mode,
>> changing the
>> > > value "
>> > >                        "of a register will make the execution log
>> > > unusable "
>> > >                        "from this point onward.  Change
>> > register %s?"),
>> > >                      gdbarch_register_name (get_regcache_arch
>> > > (regcache),
>> > > @@ -993,7 +993,7 @@
>> > >       if (RECORD_IS_REPLAY)
>> > >        {
>> > >          /* Let user choose if he wants to write memory
>> or not.  */
>> > > -         if (!nquery (_("Because GDB is in replay mode,
>> writing to
>> > > memory "
>> > > +         if (!query (_("Because GDB is in replay mode, writing to
>> > > memory "
>> > >                         "will make the execution log
>> > unusable from this
>> > > "
>> > >                         "point onward.  Write memory at
>> > address %s?"),
>> > >                       paddress (target_gdbarch, offset)))
>> > >
>> > >
>> > >
>> > >
>> >
>>
>

RE: Reverse debugging

[Marc Khouzam]

 

> -----Original Message-----
> From: Hui Zhu [mailto:teawater@gmail.com] 
> Sent: July-20-09 10:51 AM
> To: Marc Khouzam
> Cc: Nick Roberts; Daniel Jacobowitz; gdb@sources.redhat.com; 
> Michael Snyder
> Subject: Re: Reverse debugging
> 
> Hi Marc,
> 
> About change nquery to yquery,  if the user answer y, a lot of record
> entry will be delete.  So I think nquery to be default is better.
> 
> Your patch change yquery to query is OK with me.
> 
> In prec, I use a lot of yquery and nquery and looks like mi cannot
> control query very well.  So I think add some switches to let you can
> control prec more better.
> 
> On the other hand, shell we do some work to make mi support 
> query better?

I've just posted an RFC to try to get queries to work better
with frontends.  I'm hoping you won't have to change PRecord.
Please see

http://sourceware.org/ml/gdb/2009-07/msg00150.html

Thanks

Marc

> 
> Thanks,
> Hui
> 
> On Mon, Jul 20, 2009 at 21:19, Marc 
> Khouzam<marc.khouzam@ericsson.com> wrote:
> > Typo in my previous email.  Sorry.
> >
> >> (Note that I'm only suggesting to not make the query 
> default to 'Y'.
> >> There would still be a query though.)
> >
> > Should have read (no "not")
> >
> >> (Note that I'm only suggesting to make the query default to 'Y'.
> >> There would still be a query though.)
> >
> >> -----Original Message-----
> >> From: gdb-owner@sourceware.org
> >> [mailto:gdb-owner@sourceware.org] On Behalf Of Marc Khouzam
> >> Sent: Monday, July 20, 2009 8:50 AM
> >> To: Hui Zhu; Nick Roberts
> >> Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
> >> Subject: RE: Reverse debugging
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Hui Zhu [mailto:teawater@gmail.com]
> >> > Sent: Sunday, July 19, 2009 11:27 PM
> >> > To: Marc Khouzam; Nick Roberts
> >> > Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
> >> > Subject: Re: Reverse debugging
> >> >
> >> > Thanks Marc,  but what about I keep it but add some 
> switches for it?
> >> > I want keep the query to tui user.
> >> > For example:
> >> > set record query off
> >> > set record changememeory on
> >>
> >> (Note that I'm only suggesting to make the query default to 'Y'.
> >> There would still be a query though.)
> >>
> >> I've been giving the whole problem a little more thought, and I now
> >> think that it is the way queries are answered that should 
> be changed
> >> generically.
> >>
> >> I'll post a patch today and see what people think.
> >>
> >> Note that the suggestion I will post will rely on 'set 
> confirm off'.
> >> If Nick cannot use that then he'll still need you to have 
> a switch to
> >> turn these queries off.
> >>
> >> Thanks
> >>
> >> Marc
> >>
> >>
> >> >
> >> > Thanks,
> >> > Hui
> >> >
> >> >
> >> > On Sun, Jul 19, 2009 at 11:19, Marc
> >> > Khouzam<marc.khouzam@ericsson.com> wrote:
> >> > >> -----Original Message-----
> >> > >> From: Daniel Jacobowitz [mailto:drow@false.org]
> >> > >> Sent: July-17-09 10:25 AM
> >> > >> To: Marc Khouzam
> >> > >> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; 
> Michael Snyder
> >> > >> Subject: Re: Reverse debugging
> >> > >>
> >> > >> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> >> > >> > I noticed that the previous CDT GDB integration has 
> its console
> >> > >> > considered
> >> > >> > a tty.  It may be worth looking into the difference... when
> >> > >> time allows
> >> > >> > it :-)
> >> > >>
> >> > >> Wasn't someone just talking on cdt-dev about trouble with
> >> > whether DSF
> >> > >> used Spawner or not?  That'd do it.
> >> > >
> >> > > I was wrong about the console being a tty.  The old CDT GDB
> >> > integration
> >> > > console is also not a tty.  What they do though is use
> >> > > 'set confirm off'.  That makes sense since queries are
> >> > being answered
> >> > > automatically anyway.
> >> > >
> >> > > Nick, in your specific case 'confirm off' would work.  
> The default
> >> > > answer to
> >> > > 'record stop' is yes (well, there is not default, but in
> >> > that case, 'y'
> >> > > is
> >> > > chosen).  If you don't want to always 'set confirm off' you
> >> > may consider
> >> > > setting it right before sending 'record stop' and turn 
> it back on
> >> > > right after.  That may be a good enough workaround until
> >> there is a
> >> > > proper
> >> > > solution to this query problem.
> >> > >
> >> > > For me the problem for PRecord remains because the
> >> default value is
> >> > > not always what I want.  For example, in PRecord the
> >> default answer
> >> > > to changing memory and loosing the recorded history
> >> > > is "N", but as a frontend, I want to answer "Y".
> >> > >
> >> > > To fix this problem I suggest that in record.c,
> >> > > we replace 'nquery' with 'query'; that will make the
> >> > default be 'Y' when
> >> > >
> >> > > confirm is off or when there is no tty.  Note that this
> >> > seems to be what
> >> > >
> >> > > is being done everywhere else in GDB.  There is only one
> >> > case (pending
> >> > > breakpoints) that uses default queries, outside of PRecord.
> >> >  Except for
> >> > > that
> >> > > one case, it is really only PRecord that uses yquery and
> >> > nquery.  And
> >> > > the
> >> > > pending breakpoint case is not a problem for frontends 
> that use MI
> >> > > because
> >> > > the MI command does not trigger the query.
> >> > >
> >> > > Note that up to now, I've been recompiling GDB with that
> >> suggestion
> >> > > so that I can properly use PRecord in Eclipse.
> >> > >
> >> > > The below patch implements the suggestion.
> >> > >
> >> > > Thanks
> >> > >
> >> > > Marc
> >> > >
> >> > > ChangeLog
> >> > > 2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>
> >> > >
> >> > >        * record.c (record_store_registers): Replace nquery with
> >> > >        query to allow frontends to automatically answer 'y'.
> >> > >        (record_xfer_partial): Ditto.
> >> > >
> >> > >
> >> > > ### Eclipse Workspace Patch 1.0
> >> > > #P src
> >> > > Index: gdb/record.c
> >> > >
> >> ===================================================================
> >> > > RCS file: /cvs/src/src/gdb/record.c,v
> >> > > retrieving revision 1.8
> >> > > diff -u -r1.8 record.c
> >> > > --- gdb/record.c        2 Jul 2009 17:21:06 -0000       1.8
> >> > > +++ gdb/record.c        19 Jul 2009 03:06:01 -0000
> >> > > @@ -937,13 +937,13 @@
> >> > >          /* Let user choose if he wants to write register
> >> > or not.  */
> >> > >          if (regno < 0)
> >> > >            n =
> >> > > -             nquery (_("Because GDB is in replay mode,
> >> > changing the "
> >> > > +             query (_("Because GDB is in replay mode,
> >> > changing the "
> >> > >                        "value of a register will make the
> >> > execution "
> >> > >                        "log unusable from this point onward.  "
> >> > >                        "Change all registers?"));
> >> > >          else
> >> > >            n =
> >> > > -             nquery (_("Because GDB is in replay mode,
> >> changing the
> >> > > value "
> >> > > +             query (_("Because GDB is in replay mode,
> >> changing the
> >> > > value "
> >> > >                        "of a register will make the 
> execution log
> >> > > unusable "
> >> > >                        "from this point onward.  Change
> >> > register %s?"),
> >> > >                      gdbarch_register_name (get_regcache_arch
> >> > > (regcache),
> >> > > @@ -993,7 +993,7 @@
> >> > >       if (RECORD_IS_REPLAY)
> >> > >        {
> >> > >          /* Let user choose if he wants to write memory
> >> or not.  */
> >> > > -         if (!nquery (_("Because GDB is in replay mode,
> >> writing to
> >> > > memory "
> >> > > +         if (!query (_("Because GDB is in replay 
> mode, writing to
> >> > > memory "
> >> > >                         "will make the execution log
> >> > unusable from this
> >> > > "
> >> > >                         "point onward.  Write memory at
> >> > address %s?"),
> >> > >                       paddress (target_gdbarch, offset)))
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >
> 

RE: Reverse debugging

[Marc Khouzam]

Hi,

the time for 7.0 is fast approaching and I was hoping
to have a solution for setting memory during reverse debugging.
If you remember, when using Eclipse, the use of nquery() automatically
makes the answer be 'N', so I can never set memory during reverse.

We didn't reach a consensus on genericallyfixing queries for frontends and
I believe the most popular solution was to add a switch to enable/disable
this specifc query.

Hui, shall I write a patch for this?
For simplicity, I would go for 
	set record query <on | off>
which would enable/disable all precord queries.

Sound good?

Thanks

Marc


> -----Original Message-----
> From: Hui Zhu [mailto:teawater@gmail.com] 
> Sent: Sunday, July 19, 2009 11:27 PM
> To: Marc Khouzam; Nick Roberts
> Cc: Daniel Jacobowitz; gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
> 
> Thanks Marc,  but what about I keep it but add some switches for it?
> I want keep the query to tui user.
> For example:
> set record query off
> set record changememeory on
> 
> Thanks,
> Hui
> 
> 
> On Sun, Jul 19, 2009 at 11:19, Marc 
> Khouzam<marc.khouzam@ericsson.com> wrote:
> >> -----Original Message-----
> >> From: Daniel Jacobowitz [mailto:drow@false.org]
> >> Sent: July-17-09 10:25 AM
> >> To: Marc Khouzam
> >> Cc: Nick Roberts; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> >> Subject: Re: Reverse debugging
> >>
> >> On Fri, Jul 17, 2009 at 10:12:00AM -0400, Marc Khouzam wrote:
> >> > I noticed that the previous CDT GDB integration has its console
> >> > considered
> >> > a tty.  It may be worth looking into the difference... when
> >> time allows
> >> > it :-)
> >>
> >> Wasn't someone just talking on cdt-dev about trouble with 
> whether DSF
> >> used Spawner or not?  That'd do it.
> >
> > I was wrong about the console being a tty.  The old CDT GDB 
> integration
> > console is also not a tty.  What they do though is use
> > 'set confirm off'.  That makes sense since queries are 
> being answered
> > automatically anyway.
> >
> > Nick, in your specific case 'confirm off' would work.  The default
> > answer to
> > 'record stop' is yes (well, there is not default, but in 
> that case, 'y'
> > is
> > chosen).  If you don't want to always 'set confirm off' you 
> may consider
> > setting it right before sending 'record stop' and turn it back on
> > right after.  That may be a good enough workaround until there is a
> > proper
> > solution to this query problem.
> >
> > For me the problem for PRecord remains because the default value is
> > not always what I want.  For example, in PRecord the default answer
> > to changing memory and loosing the recorded history
> > is "N", but as a frontend, I want to answer "Y".
> >
> > To fix this problem I suggest that in record.c,
> > we replace 'nquery' with 'query'; that will make the 
> default be 'Y' when
> >
> > confirm is off or when there is no tty.  Note that this 
> seems to be what
> >
> > is being done everywhere else in GDB.  There is only one 
> case (pending
> > breakpoints) that uses default queries, outside of PRecord. 
>  Except for
> > that
> > one case, it is really only PRecord that uses yquery and 
> nquery.  And
> > the
> > pending breakpoint case is not a problem for frontends that use MI
> > because
> > the MI command does not trigger the query.
> >
> > Note that up to now, I've been recompiling GDB with that suggestion
> > so that I can properly use PRecord in Eclipse.
> >
> > The below patch implements the suggestion.
> >
> > Thanks
> >
> > Marc
> >
> > ChangeLog
> > 2009-07-18  Marc Khouzam  <marc.khouzam@ericsson.com>
> >
> >        * record.c (record_store_registers): Replace nquery with
> >        query to allow frontends to automatically answer 'y'.
> >        (record_xfer_partial): Ditto.
> >
> >
> > ### Eclipse Workspace Patch 1.0
> > #P src
> > Index: gdb/record.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/record.c,v
> > retrieving revision 1.8
> > diff -u -r1.8 record.c
> > --- gdb/record.c        2 Jul 2009 17:21:06 -0000       1.8
> > +++ gdb/record.c        19 Jul 2009 03:06:01 -0000
> > @@ -937,13 +937,13 @@
> >          /* Let user choose if he wants to write register 
> or not.  */
> >          if (regno < 0)
> >            n =
> > -             nquery (_("Because GDB is in replay mode, 
> changing the "
> > +             query (_("Because GDB is in replay mode, 
> changing the "
> >                        "value of a register will make the 
> execution "
> >                        "log unusable from this point onward.  "
> >                        "Change all registers?"));
> >          else
> >            n =
> > -             nquery (_("Because GDB is in replay mode, changing the
> > value "
> > +             query (_("Because GDB is in replay mode, changing the
> > value "
> >                        "of a register will make the execution log
> > unusable "
> >                        "from this point onward.  Change 
> register %s?"),
> >                      gdbarch_register_name (get_regcache_arch
> > (regcache),
> > @@ -993,7 +993,7 @@
> >       if (RECORD_IS_REPLAY)
> >        {
> >          /* Let user choose if he wants to write memory or not.  */
> > -         if (!nquery (_("Because GDB is in replay mode, writing to
> > memory "
> > +         if (!query (_("Because GDB is in replay mode, writing to
> > memory "
> >                         "will make the execution log 
> unusable from this
> > "
> >                         "point onward.  Write memory at 
> address %s?"),
> >                       paddress (target_gdbarch, offset)))
> >
> >
> >
> >
> 

RE: Reverse debugging

[Nick Roberts]

 > We do have a console and we do want it to be fully supported :-)
 > But all commands sent from the console are redirected through
 > our normal MI channel and I think this is the reason we
 > are not a tty in that case.
 > 
 > For example when turning off record from that console or from
 > the eclipse buttons I get: 
 > "Delete recorded log and stop recording?(y or n) [answered Y; input not
 > from terminal]"

It seems strange not to use a tty for the console since it is a terminal.  It
allows you to change the terminal mode, although admittedly I've not found a
need for this.  Also if you wanted to use readline, I guess it would need a
tty.

 > I noticed that the previous CDT GDB integration has its console
 > considered
 > a tty.  It may be worth looking into the difference... when time allows
 > it :-)

 > ...
 > So you start GDB in CLI mode?

For the current and next release (23.x), yes.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Reverse debugging

[Daniel Jacobowitz]

On Sat, Jul 18, 2009 at 01:06:36PM +1200, Nick Roberts wrote:
> It seems strange not to use a tty for the console since it is a terminal.  It
> allows you to change the terminal mode, although admittedly I've not found a
> need for this.  Also if you wanted to use readline, I guess it would need a
> tty.

I've found it works much better to handle any readline-like behavior
in the front end; then use -interpreter-exec to talk to GDB.  This
lets you reliably get MI notifications for actions, etc.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Reverse debugging

[Marc Khouzam]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org] 
> Sent: Saturday, July 18, 2009 12:00 AM
> To: Nick Roberts
> Cc: Marc Khouzam; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
> 
> On Sat, Jul 18, 2009 at 01:06:36PM +1200, Nick Roberts wrote:
> > It seems strange not to use a tty for the console since it 
> is a terminal.  It
> > allows you to change the terminal mode, although admittedly 
> I've not found a
> > need for this.  Also if you wanted to use readline, I guess 
> it would need a
> > tty.
> 
> I've found it works much better to handle any readline-like behavior
> in the front end; then use -interpreter-exec to talk to GDB.  This
> lets you reliably get MI notifications for actions, etc.

If I understand correctly your point is that using GDB to handle
readline behavior will lockup the GDB-frontend communication and will
delay any MI notifications.  If that is what you meant, then I wasnted
to bring up the fact that such a problem is occuring now with
scripting (with the 'define' command).

If a user uses the 'define' command in the eclipse console, GDB is now
locked listening on the secondary prompt ('>').  If any MI commands 
happened to be sent to GDB during that time, they get swallowed and 
Eclipse gets all messed up.

I was considering handling the secondary prompt within eclipse and then 
sending all those sub commands to GDB at once.  To do this, I was 
wondering a couple of things:

- is there anyway that something type at the secondary prompt
  can cause a failure?  What I mean is: is it true that
  except for ^C and 'end', anything will be accepted at the
  secondary prompt, and the next line will be a new secondary
  prompt.

- can I 'undefine' a user command?

- are there many commands that trigger the secondary prompt?
  I am aware of 'define' and 'actions'

Thanks

Marc

Re: Reverse debugging

[Hui Zhu]

On Tue, Jul 14, 2009 at 09:28, Nick Roberts<nickrob@snap.net.nz> wrote:
>  > That's because target exec does not support reverse,
>  > but target record does.  Reverse is also potentially
>  > supported under target remote, depending on what remote
>  > target you're connected to.
>  >
>  > > In the "Reverse Execution" node of the GDB manual it talks about
>  > > "a target environment that supports reverse execution" but doesn't clarify
>  > > what those targets are.  The node "Process Record and Replay" comes next
>  > > in the manual but these two seem to be inimately related.
>  >
>  > Process record (target record) is one of a small number of
>  > targets that currently support reverse debugging.  The others,
>  > so far, are all remote targets (eg. SID from Red Hat, and
>  > Simics from Virtutech).
>  >...
>
> Thanks for these answers, I find them more lucid than the manual.  If I try
> to reverse a remote target using gdbserver (actually on host/local machine -
> x86_64 this time), I'm not told that the target doesn't support this command
> but reverse-next works just like next until I hit a function:
>
> (gdb) reverse-next
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000000000400521 in printf@plt ()
> Current language:  auto; currently asm
> (gdb)

Looks like you use an old gdb-cvs version with amd64,right?

1. Please use the head version of gdb.  It will tell you that amd64
doesn't support prec now.
2. You can try the patch that I post to make gdb support amd64.  You
can get the link and other message from
http://sourceware.org/gdb/wiki/ReversibleDebugging

Thanks,
Hui

Re: Reverse debugging

[Nick Roberts]

 > > ...If I try to reverse a remote target using gdbserver (actually on
 > > host/local machine - x86_64 this time), I'm not told that the target
 > > doesn't support this command but reverse-next works just like next until
 > > I hit a function:
 > >
 > > (gdb) reverse-next
 > >
 > > Program received signal SIGTRAP, Trace/breakpoint trap.
 > > 0x0000000000400521 in printf@plt ()
 > > Current language:  auto; currently asm
 > > (gdb)
 > 
 > Looks like you use an old gdb-cvs version with amd64,right?

I didn't think I had an old gdb-cvs version - at least not more than a few
days old.

 > 1. Please use the head version of gdb.  It will tell you that amd64
 > doesn't support prec now.

I've tried it again and it does, indeed, report it.  Thanks.

 > 2. You can try the patch that I post to make gdb support amd64.  You
 > can get the link and other message from
 > http://sourceware.org/gdb/wiki/ReversibleDebugging

I can try it if you wish but I don't have access to any real embedded
targets and have only used "target remote" through gdbserver on my local
machine.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: Reverse debugging

[Jakob Engblom]

 
> > Is there a GDB command that shows if process recording is started/stopped?
> > "target record" doesn't appear to influence the output of 'info target".
> 
> Good question.  We've been discussing the same question under
> the thread "Testing of reverse debug commands", and I think
> we're leaning toward the conclusion "we need such a command".

I think this would be useful. It is always nice ot know what the capabilities of
a debug system is.

I know this reply is about a month late, but only now after vacations have I had
time to catch up to the discussion. 


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
________________________________________________________