Process record and replay checked in to main trunk

Process record and replay checked in to main trunk

[Hui Zhu]

Hi guys,

Process record and replay make gdb can record inferior execute log and
replay (include reverse debug).
Now, it support I386-Linux single-thread single-inferior native debug.


It was checked in today.
Thanks for evey people that spent time on process record.  Precord
can't be a part of gdb without your help.  Thank you very much.  :)


And precord still has a long way to go.  There have a lot of thing need to do:

1. Support i386 more better.  Now, precord doesn't support mmx insns,
support fp insns not very well and doesn't support a lot of insns.

2. Support more arches.  X86-64 is the first one (linux-record.c).
MIPS, ARM and so on.

3. Support memory free better.  Now, precord just can output a warning
for memumap.  It can do nothing when there is a sys_brk to free the
memory.
I had make a patch to output a warning when there is a sys_brk to free
the memory and make a plan to make precord can support free memory.
I will keep work on it.

4. Support multi-thread and multi-inferior.
I remember Pedro make a patch for reverse debug resume.  I think we
need this patch when multi-inferior check in.

5. Make record speed up and need less memory.
I have made a plan to make p record doesn't record execution log of
some functions (It can set), for example some functions in glibc.

6. Make execution log can dump out to be a file and can replay for next time.
Maybe it can make together with coredump support.  It must be a cool
function.  :)

Guys, please work on it if you interesting with some of them.  And
feel free tell me your ideas and comments.  It will help precord a
lot.


Thanks,
Hui

RE: Process record and replay checked in to main trunk

[Marc Khouzam]

 

> Process record and replay make gdb can record inferior execute log and
> replay (include reverse debug).
> Now, it support I386-Linux single-thread single-inferior native debug.
> 
> It was checked in today.

Congratulations!
I've checked-out the new HEAD and running PRecord in Eclipse
with no patches.

> Guys, please work on it if you interesting with some of them.  And
> feel free tell me your ideas and comments.  It will help precord a
> lot.

Here are some things I think would be nice:

1- The handling of queries in PRecord as we discussed in
http://sourceware.org/ml/gdb/2009-03/msg00194.html

2- speed (but you already mentioned you will work on this)

3- Some MI support
	- 'record' and 'stoprecord' could have an MI equivalent
	- trying to get the MI commands for Reverse debugging done
	- *stopped MI event could/should have a special 'reason' field
when
	  it is triggered because Replay execution is finished.
	  Currently, there is no 'reason' field in this case.
	  Having the 'reason' field would allow a fronten to optionally
	  resume the execution at that point, instead of mysteriously
	  stopping when the Replay execution is finished.

I'm sure more suggestion will arise as people start using it.

Again, good work!

Marc

Re: Process record and replay checked in to main trunk

[Michael Snyder]

Marc Khouzam wrote:
>  
> 
>> Process record and replay make gdb can record inferior execute log and
>> replay (include reverse debug).
>> Now, it support I386-Linux single-thread single-inferior native debug.
>>
>> It was checked in today.
> 
> Congratulations!

Yes, congratulations!

The work itself is a great accomplishment, and
pushing it through the approval process has been
a second accomplishment of almost equal magnitude!

I appreciate all of your hard work, as well as the
time invested by all the maintainers in review and
discussion.  Good work, all!

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Thu, 30 Apr 2009 15:59:30 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: Pedro Alves <pedro@codesourcery.com>, Marc Khouzam <marc.khouzam@ericsson.com>, 
> 	Michael Snyder <msnyder@vmware.com>, Thiago Jung Bauermann <bauerman@br.ibm.com>, Eli Zaretskii <eliz@gnu.org>, 
> 	Mark Kettenis <mark.kettenis@xs4all.nl>
> 
> Process record and replay make gdb can record inferior execute log and
> replay (include reverse debug).
> Now, it support I386-Linux single-thread single-inferior native debug.
> 
> 
> It was checked in today.
> Thanks for evey people that spent time on process record.  Precord
> can't be a part of gdb without your help.  Thank you very much.  :)

Thanks.  I clarified and improved the section in the manual with the
patch below (committed).

What I think is still missing from the manual is a few sentences that
would explain when this target is useful.  Can you provide such ``war
stories''?  I will then add them to the manual.


2009-05-01  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Process Record and Replay): Improve and clarify.
	Add index entries.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.588
diff -u -r1.588 gdb.texinfo
--- gdb.texinfo	30 Apr 2009 03:24:48 -0000	1.588
+++ gdb.texinfo	1 May 2009 09:10:11 -0000
@@ -134,7 +134,7 @@
 * Running::                     Running programs under @value{GDBN}
 * Stopping::                    Stopping and continuing
 * Reverse Execution::           Running programs backward
-* Process record and replay::   Recording inferior's execution and replaying it
+* Process Record and Replay::   Recording inferior's execution and replaying it
 * Stack::                       Examining the stack
 * Source::                      Examining source files
 * Data::                        Examining data
@@ -5003,97 +5003,119 @@
 @end table
 
 
-@node Process record and replay
-@chapter Recording inferior's execution and replaying it
+@node Process Record and Replay
+@chapter Recording Inferior's Execution and Replaying It
 @cindex process record and replay
 @cindex recording inferior's execution and replaying it
 
-In a architecture environment that supports process record and replay,
-process record and replay target can record a log of the process execution,
-and replay it with both forward and reverse execute commands.
-
-When this target is in use, if the execution log includes the record for
-the next instruction, @value{GDBN} will debug in replay mode.  So inferior
-will not really execute and all the execution events are taken from the
-execution log.  Just the values of registers (include pc register) and
-memory of the inferior will be changed.
+In an architecture environment that supports process recording and
+replay, a special @dfn{process record and replay} target can record a
+log of the process execution, and replay it later with both forward
+and reverse execution commands.
+
+@cindex replay mode
+When this target is in use, if the execution log includes the record
+for the next instruction, @value{GDBN} will debug in @dfn{replay
+mode}.  In the replay mode, the inferior does not really execute code
+instructions.  Instead, all the events that normally happen during
+code execution are taken from the execution log.  While code is not
+really executed in replay mode, the values of registers (including the
+program counter register) and the memory of the inferior are still
+changed as they normally would.
+
+@cindex record mode
+If the record for the next instruction is not in the execution log,
+@value{GDBN} will debug in @dfn{record mode}.  In this mode, the
+inferior executes normally, and @value{GDBN} records the execution log
+for future replay.
 
-Otherwise, @value{GDBN} will debug in record mode.  So inferior will
-execute normally and @value{GDBN} will record the execution log.
-
-If you are debugging in a architecture environment that supports
-process record and replay, @value{GDBN} provides the following commands.
+For architecture environments that support process record and replay,
+@value{GDBN} provides the following commands:
 
 @table @code
 @kindex target record
 @kindex record
 @kindex rec
 @item target record
-This a standard command to start process record and replay target.
-Process record and replay target can only debug a process that already
-running.  Therefore you need to first start the process @code{run},
-and then start the recording @code{target record}.
-
-Both @code{record} and @code{rec} are the aliases of @code{target record}.
-
-Displaced stepping function will disable when process record and replay
-target is opened.  Because process record and replay target doesn't
-support displaced stepping function.
-
-If inferior in non-stop mode (non-stop) or in asynchronous mode
-(target-async), process record and replay target can't be open because
-it doesn't support these two modes.
+This command starts the process record and replay target.  The process
+record and replay target can only debug a process that is already
+running.  Therefore, you need first to start the process with the
+@kbd{run} or @kbd{start} commands, and then start the recording with
+the @kbd{target record} command.
+
+Both @code{record} and @code{rec} are aliases of @code{target record}.
+
+@cindex displaced stepping, and process record and replay
+Displaced stepping (@pxref{Maintenance Commands,, displaced stepping})
+will be automatically disabled when process record and replay target
+is started.  That's because the process record and replay target
+doesn't support displaced stepping.
+
+@cindex non-stop mode, and process record and replay
+@cindex asynchronous execution, and process record and replay
+If the inferior is in the non-stop mode (@pxref{Non-Stop Mode}) or in
+the asynchronous execution mode (@pxref{Background Execution}), the
+process record and replay target cannot be started because it doesn't
+support these two modes.
 
 @kindex record stop
 @kindex rec s
 @item record stop
-Stop process record and replay target at once.  When Process record and
-replay target stops, all the execution log will be deleted and the inferior
-will either be terminated, or remain in its final state.
-
-When you stop the process record and replay target in record mode (at the
-end of the execution log), the inferior will be stopped at the next
-instruction that would have been recorded.  In other words, if you record
-for a while and then stop recording, the inferior process will be left in
-the same state as if recording never happened.
-
-On the other hand, if the process record and replay target is stopped while
-in replay mode (that is, not at the end of the execution log but at some
-earlier point), the inferior process will become ``live'' at that earlier state,
-and it will then be possible to continue debugging the process ``live'' from
-that state.
+Stop the process record and replay target.  When process record and
+replay target stops, the entire execution log will be deleted and the
+inferior will either be terminated, or will remain in its final state.
+
+When you stop the process record and replay target in record mode (at
+the end of the execution log), the inferior will be stopped at the
+next instruction that would have been recorded.  In other words, if
+you record for a while and then stop recording, the inferior process
+will be left in the same state as if the recording never happened.
+
+On the other hand, if the process record and replay target is stopped
+while in replay mode (that is, not at the end of the execution log,
+but at some earlier point), the inferior process will become ``live''
+at that earlier state, and it will then be possible to continue the
+usual ``live'' debugging of the process from that state.
 
-When the inferior process exits, or @value{GDBN} detaches from it, process
-record and replay target will automatically stop itself.
+When the inferior process exits, or @value{GDBN} detaches from it,
+process record and replay target will automatically stop itself.
 
 @kindex set record insn-number-max
 @item set record insn-number-max @var{limit}
 Set the limit of instructions to be recorded.  Default value is 200000.
 
-In this case, if record instructions number is bigger than @var{limit},
-@value{GDBN} will auto delete the earliest recorded instruction execute
-log.
-
-If set to 0, @value{GDBN} will not delete the earliest recorded instruction
-execute log.  Record instructions number limit function will disable.
+If @var{limit} is a positive number, then @value{GDBN} will start
+deleting instructions from the log once the number of the record
+instructions becomes greater than @var{limit}.  For every new recorded
+instruction, @value{GDBN} will delete the earliest recorded
+instruction to keep the number of recorded instructions at the limit.
+(Since deleting recorded instructions loses information, @value{GDBN}
+lets you control what happens when the limit is reached, by means of
+the @code{stop-at-limit} option, described below.)
+
+If @var{limit} is zero, @value{GDBN} will never delete recorded
+instructions from the execution log.  The number of recorded
+instructions is unlimited in this case.
 
 @kindex show record insn-number-max
 @item show record insn-number-max
-Show the value of recorded instructions limit.
+Show the limit of instructions to be recorded.
 
 @kindex set record stop-at-limit
-@item set record stop-at-limit on
-Set the behavior when record instructions limit is reached.
-This is the default mode.  Meaning that @value{GDBN} will stop ask user
-want close @code{record stop-at-limit} or stop inferior.
-
-@item set record stop-at-limit off
-This mean that @value{GDBN} will auto delete the oldest record to make
-room for each new one.
+@item set record stop-at-limit
+Control the behavior when the number of recorded instructions reaches
+the limit.  If ON (the default), @value{GDBN} will stop when the limit
+is reached for the first time and ask you whether you want to stop the
+inferior or continue running it and recording the execution log.  If
+you decide to continue recording, each new recorded instruction will
+cause the oldest one to be deleted.
+
+If this option is OFF, @value{GDBN} will automatically delete the
+oldest record to make room for each new one, without asking.
 
 @kindex show record stop-at-limit
 @item show record stop-at-limit
-Show the value of record stop-at-limit.
+Show the current setting of @code{stop-at-limit}.
 
 @kindex info record insn-number
 @item info record insn-number
@@ -5102,9 +5124,9 @@
 @kindex record delete
 @kindex rec del
 @item record delete
-When record target running in replay mode (``in the past''), delete the
+When record target runs in replay mode (``in the past''), delete the
 subsequent execution log and begin to record a new execution log starting
-from the current address.  It means you will abandon the previously
+from the current address.  This means you will abandon the previously
 recorded ``future'' and begin recording a new ``future''.
 @end table
 

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

May I suggest the following changes in some of the doc strings related
to this feature?  In addition to rewording, it also reformats the way
the strings are presented, so that it is easy to spot when we exceed
the width of the screen and need to break long lines.

2009-05-01  Eli Zaretskii  <eliz@gnu.org>

	* record.c (_initialize_record): Reformat and clarify doc strings
	for stop-at-limit and insn-number-max.

Index: gdb/record.c
===================================================================
RCS file: /cvs/src/src/gdb/record.c,v
retrieving revision 1.2
diff -u -r1.2 record.c
--- gdb/record.c	30 Apr 2009 02:58:37 -0000	1.2
+++ gdb/record.c	1 May 2009 09:24:01 -0000
@@ -1259,28 +1259,21 @@
 
   /* Record instructions number limit command.  */
   add_setshow_boolean_cmd ("stop-at-limit", no_class,
-			    &record_stop_at_limit,
-			    _("Set whether record/replay stop when "
-			      "record/replay buffer becomes full."),
-			    _("Show whether record/replay stop when "
-			      "record/replay buffer becomes full."),
-	                    _("Enable is default value.\n"
-	                      "When enabled, if the record/replay buffer "
-			      "becomes full,\n"
-                              "ask user what to do.\n"
-                              "When disabled, if the record/replay buffer "
-			      "becomes full,\n"
-                              "delete it and start new recording."),
+			    &record_stop_at_limit, _("\
+Set whether record/replay stops when record/replay buffer becomes full."), _("\
+Show whether record/replay stops when record/replay buffer becomes full."), _("\
+Default is ON.\n\
+When ON, if the record/replay buffer becomes full, ask user what to do.\n\
+When OFF, if the record/replay buffer becomes full,\n\
+delete the oldest recorded instruction to make room for each new one."),
 			    NULL, NULL,
                             &set_record_cmdlist, &show_record_cmdlist);
   add_setshow_zinteger_cmd ("insn-number-max", no_class,
 			    &record_insn_max_num,
 			    _("Set record/replay buffer limit."),
-			    _("Show record/replay buffer limit."),
-			    _("Set the maximum number of instructions to be "
-                              "stored in the\n"
-                              "record/replay buffer.  "
-                              "Zero means unlimited (default 200000)."),
+			    _("Show record/replay buffer limit."), _("\
+Set the maximum number of instructions to be stored in the\n\
+record/replay buffer.  Zero means unlimited.  Default is 200000."),
 			    set_record_insn_max_num,
 			    NULL, &set_record_cmdlist, &show_record_cmdlist);
   add_cmd ("insn-number", class_obscure, show_record_insn_number,

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

It would be nice if i386-tdep.c had some comments about what it takes
for another x86 target to add support for process recording and
replay.  Apologies if it's already described somewhere and I missed
it.

It looks like all is needed is to define suitable functions for
tdep->i386_intx80_record and tdep->i386_sysenter_record, is that
right?  (If so, why so Linux-centric names?)

Also, some architectural overview of how the record/replay target
works would be nice, either in the comments or in gdbint.texinfo.  For
example, just looking at i386_linux_intx80_sysenter_record, I cannot
understand how it succeed to record both the arguments to the syscall
and the return value.  The syscall itself does not happen inside
record_linux_system_call, that just records the syscall parameters and
data buffers, right?  And recording happens _before_ the instruction
being recorded executes, right?  So how come
i386_linux_intx80_sysenter_record can use EAX as the syscall number
and immediately after the call to record_linux_system_call treat the
value of EAX as the value returned by the syscall?  What am I missing
here?

It probably doesn't help that I don't know enough about how the target
stack works, but that isn't described, either, at least not in
target.[ch], right?  The only thing I found is some very high-level
description at the beginning of target.h.

Re: Process record and replay checked in to main trunk

[Hui Zhu]

Hi Eli,

On Fri, May 1, 2009 at 17:15, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 30 Apr 2009 15:59:30 +0800
>> From: Hui Zhu <teawater@gmail.com>
>> Cc: Pedro Alves <pedro@codesourcery.com>, Marc Khouzam <marc.khouzam@ericsson.com>,
>>       Michael Snyder <msnyder@vmware.com>, Thiago Jung Bauermann <bauerman@br.ibm.com>, Eli Zaretskii <eliz@gnu.org>,
>>       Mark Kettenis <mark.kettenis@xs4all.nl>
>>
>> Process record and replay make gdb can record inferior execute log and
>> replay (include reverse debug).
>> Now, it support I386-Linux single-thread single-inferior native debug.
>>
>>
>> It was checked in today.
>> Thanks for evey people that spent time on process record.  Precord
>> can't be a part of gdb without your help.  Thank you very much.  :)
>
> Thanks.  I clarified and improved the section in the manual with the
> patch below (committed).

That is great.  Thanks.

>
> What I think is still missing from the manual is a few sentences that
> would explain when this target is useful.  Can you provide such ``war
> stories''?  I will then add them to the manual.

Which sentences? ``war stories''?
Do you mean is internal doc?


Thanks,
Hui

Re: Process record and replay checked in to main trunk

[Hui Zhu]

That is very good for me.
Thanks.

Hui

On Fri, May 1, 2009 at 17:26, Eli Zaretskii <eliz@gnu.org> wrote:
> May I suggest the following changes in some of the doc strings related
> to this feature?  In addition to rewording, it also reformats the way
> the strings are presented, so that it is easy to spot when we exceed
> the width of the screen and need to break long lines.
>
> 2009-05-01  Eli Zaretskii  <eliz@gnu.org>
>
>        * record.c (_initialize_record): Reformat and clarify doc strings
>        for stop-at-limit and insn-number-max.
>
> Index: gdb/record.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/record.c,v
> retrieving revision 1.2
> diff -u -r1.2 record.c
> --- gdb/record.c        30 Apr 2009 02:58:37 -0000      1.2
> +++ gdb/record.c        1 May 2009 09:24:01 -0000
> @@ -1259,28 +1259,21 @@
>
>   /* Record instructions number limit command.  */
>   add_setshow_boolean_cmd ("stop-at-limit", no_class,
> -                           &record_stop_at_limit,
> -                           _("Set whether record/replay stop when "
> -                             "record/replay buffer becomes full."),
> -                           _("Show whether record/replay stop when "
> -                             "record/replay buffer becomes full."),
> -                           _("Enable is default value.\n"
> -                             "When enabled, if the record/replay buffer "
> -                             "becomes full,\n"
> -                              "ask user what to do.\n"
> -                              "When disabled, if the record/replay buffer "
> -                             "becomes full,\n"
> -                              "delete it and start new recording."),
> +                           &record_stop_at_limit, _("\
> +Set whether record/replay stops when record/replay buffer becomes full."), _("\
> +Show whether record/replay stops when record/replay buffer becomes full."), _("\
> +Default is ON.\n\
> +When ON, if the record/replay buffer becomes full, ask user what to do.\n\
> +When OFF, if the record/replay buffer becomes full,\n\
> +delete the oldest recorded instruction to make room for each new one."),
>                            NULL, NULL,
>                             &set_record_cmdlist, &show_record_cmdlist);
>   add_setshow_zinteger_cmd ("insn-number-max", no_class,
>                            &record_insn_max_num,
>                            _("Set record/replay buffer limit."),
> -                           _("Show record/replay buffer limit."),
> -                           _("Set the maximum number of instructions to be "
> -                              "stored in the\n"
> -                              "record/replay buffer.  "
> -                              "Zero means unlimited (default 200000)."),
> +                           _("Show record/replay buffer limit."), _("\
> +Set the maximum number of instructions to be stored in the\n\
> +record/replay buffer.  Zero means unlimited.  Default is 200000."),
>                            set_record_insn_max_num,
>                            NULL, &set_record_cmdlist, &show_record_cmdlist);
>   add_cmd ("insn-number", class_obscure, show_record_insn_number,
>

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Sat, 2 May 2009 01:02:33 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org, pedro@codesourcery.com, 
> 	marc.khouzam@ericsson.com, msnyder@vmware.com, bauerman@br.ibm.com, 
> 	mark.kettenis@xs4all.nl
> 
> > What I think is still missing from the manual is a few sentences that
> > would explain when this target is useful.  Can you provide such ``war
> > stories''?  I will then add them to the manual.
> 
> Which sentences? ``war stories''?
> Do you mean is internal doc?

No, I mean description of when this target is useful in real life, and
how you will use it.  In other words, put yourself in a place of
someone who reads the manual about the record/replay target and asks
him/herself "why should I care about this new feature?"  Then try to
answer that question.  And try to answer it so that the reader will
wonder how could she ever get by without this feature before.

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Sat, 2 May 2009 01:08:48 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
> 
> That is very good for me.

Thanks, I committed it.

Re: Process record and replay checked in to main trunk

[Hui Zhu]

Hi Eli,

On Fri, May 1, 2009 at 21:27, Eli Zaretskii <eliz@gnu.org> wrote:
> It would be nice if i386-tdep.c had some comments about what it takes
> for another x86 target to add support for process recording and
> replay.  Apologies if it's already described somewhere and I missed
> it.
>
> It looks like all is needed is to define suitable functions for
> tdep->i386_intx80_record and tdep->i386_sysenter_record, is that
> right?  (If so, why so Linux-centric names?)

The intx80 and sysenter function pointers is the interface for
i386-os-tdep code to set intx86 insn and sysenter special record
functions.
Because some os (linux) have special function in intx80 and sysenter
(system call).

So, in other arch, maybe there will have other interface.  For
example, arm will have a swi interface, mips will have a syscall
interface.

>
> Also, some architectural overview of how the record/replay target
> works would be nice, either in the comments or in gdbint.texinfo.  For
> example, just looking at i386_linux_intx80_sysenter_record, I cannot
> understand how it succeed to record both the arguments to the syscall
> and the return value.  The syscall itself does not happen inside
> record_linux_system_call, that just records the syscall parameters and
> data buffers, right?  And recording happens _before_ the instruction
> being recorded executes, right?  So how come
> i386_linux_intx80_sysenter_record can use EAX as the syscall number
> and immediately after the call to record_linux_system_call treat the
> value of EAX as the value returned by the syscall?  What am I missing
> here?

This is because all record work will be done before insn execute.
Before insn execute, p record parse this insn.  Find out which
register and memory will be changed in this insn.  Record the old
value of the reg and mem.
So, syscall doesn't really need execute in function
i386_linux_intx80_sysenter_record.

>
> It probably doesn't help that I don't know enough about how the target
> stack works, but that isn't described, either, at least not in
> target.[ch], right?  The only thing I found is some very high-level
> description at the beginning of target.h.
>
I don't know which doc have the description for.  Maybe read code
target.c:update_current_target will help to make clear stack works.


All of them are very good questions.  Please tell me if you still have
problems with them.


Thanks,
Hui

Re: Process record and replay checked in to main trunk

[Hui Zhu]

On Sat, May 2, 2009 at 01:55, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 2 May 2009 01:02:33 +0800
>> From: Hui Zhu <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org, pedro@codesourcery.com,
>>       marc.khouzam@ericsson.com, msnyder@vmware.com, bauerman@br.ibm.com,
>>       mark.kettenis@xs4all.nl
>>
>> > What I think is still missing from the manual is a few sentences that
>> > would explain when this target is useful.  Can you provide such ``war
>> > stories''?  I will then add them to the manual.
>>
>> Which sentences? ``war stories''?
>> Do you mean is internal doc?
>
> No, I mean description of when this target is useful in real life, and
> how you will use it.  In other words, put yourself in a place of
> someone who reads the manual about the record/replay target and asks
> him/herself "why should I care about this new feature?"  Then try to
> answer that question.  And try to answer it so that the reader will
> wonder how could she ever get by without this feature before.
>

I got it.  I will try to deal with it.

I am not a native speaker and poor english ability.
Could some people help me with it?

Thanks,
Hui

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Sun, 3 May 2009 21:54:19 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org
> 
> On Fri, May 1, 2009 at 21:27, Eli Zaretskii <eliz@gnu.org> wrote:
> > It would be nice if i386-tdep.c had some comments about what it takes
> > for another x86 target to add support for process recording and
> > replay.  Apologies if it's already described somewhere and I missed
> > it.
> >
> > It looks like all is needed is to define suitable functions for
> > tdep->i386_intx80_record and tdep->i386_sysenter_record, is that
> > right?  (If so, why so Linux-centric names?)
> 
> The intx80 and sysenter function pointers is the interface for
> i386-os-tdep code to set intx86 insn and sysenter special record
> functions.
> Because some os (linux) have special function in intx80 and sysenter
> (system call).
> 
> So, in other arch, maybe there will have other interface.  For
> example, arm will have a swi interface, mips will have a syscall
> interface.

Right, but I was asking about another _x86_ target, not just any
target.  Is there anything an i386 target needs to do to get process
record and replay work, except define suitable i386_intx80_record and
i386_sysenter_record functions?

> > just looking at i386_linux_intx80_sysenter_record, I cannot
> > understand how it succeed to record both the arguments to the syscall
> > and the return value.  The syscall itself does not happen inside
> > record_linux_system_call, that just records the syscall parameters and
> > data buffers, right?  And recording happens _before_ the instruction
> > being recorded executes, right?  So how come
> > i386_linux_intx80_sysenter_record can use EAX as the syscall number
> > and immediately after the call to record_linux_system_call treat the
> > value of EAX as the value returned by the syscall?  What am I missing
> > here?
> 
> This is because all record work will be done before insn execute.
> Before insn execute, p record parse this insn.  Find out which
> register and memory will be changed in this insn.  Record the old
> value of the reg and mem.

Okay, and when will they record the new values of the registers and
memory affected by the syscall?

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Sun, 3 May 2009 22:15:34 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org
> 
> > No, I mean description of when this target is useful in real life, and
> > how you will use it.  In other words, put yourself in a place of
> > someone who reads the manual about the record/replay target and asks
> > him/herself "why should I care about this new feature?"  Then try to
> > answer that question.  And try to answer it so that the reader will
> > wonder how could she ever get by without this feature before.
> >
> 
> I got it.  I will try to deal with it.

Thanks.

> I am not a native speaker and poor english ability.
> Could some people help me with it?

Don't worry about that.  Just write what you can, and I will take care
of rephrasing it as needed.

By gathering bits and pieces, I'm beginning to understand that process
record/replay is part of our support for ``reversible debugging''.  If
that is true, would people agree to have a chapter by that name in the
manual, explaining what is this all about, and to move all the related
sections into that chapter?

RE: Process record and replay checked in to main trunk

[Marc Khouzam]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Hui Zhu
> Sent: Sunday, May 03, 2009 10:16 AM
> To: Eli Zaretskii
> Cc: gdb-patches@sourceware.org
> Subject: Re: Process record and replay checked in to main trunk
> 
> On Sat, May 2, 2009 at 01:55, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Sat, 2 May 2009 01:02:33 +0800
> >> From: Hui Zhu <teawater@gmail.com>
> >> Cc: gdb-patches@sourceware.org, pedro@codesourcery.com,
> >>       marc.khouzam@ericsson.com, msnyder@vmware.com, 
> bauerman@br.ibm.com,
> >>       mark.kettenis@xs4all.nl
> >>
> >> > What I think is still missing from the manual is a few 
> sentences that
> >> > would explain when this target is useful.  Can you 
> provide such ``war
> >> > stories''?  I will then add them to the manual.
> >>
> >> Which sentences? ``war stories''?
> >> Do you mean is internal doc?
> >
> > No, I mean description of when this target is useful in 
> real life, and
> > how you will use it.  In other words, put yourself in a place of
> > someone who reads the manual about the record/replay target and asks
> > him/herself "why should I care about this new feature?"  Then try to
> > answer that question.  And try to answer it so that the reader will
> > wonder how could she ever get by without this feature before.
> >
> 
> I got it.  I will try to deal with it.
> 
> I am not a native speaker and poor english ability.
> Could some people help me with it?

These points will not be a surprise to anyone, but I figure 
they may help get the ball rolling.
Some of the values that I find in Process Record and Replay are:

a) Debugging a problem that requires a lot of user input.  

Say my software is a graphical application and I get a 
report that a specific long sequence of user-interface operations 
causes a bug.  Fixing the bug requires me to reproduce it by 
repeating the many UI operations until I arrive at the point of 
execution where the bug occurs.  If I have to go over the problematic
part of the execution multiple times, traditional debugging requires
me to manually repeat the long sequence of UI steps over and over, 
until I have collected all the necessary information.

With Process Record and Replay, the pressure of obtaining as much 
information as possible in a single run is removed.  If I need to 
collect more information that I originally thought, it is now possible 
to simply reverse the execution up to the point I'm interested in, and 
repeat the execution forward again, collecting the info that was missed.
The long sequence of UI steps need only be done once.

b) Debugging a race condition

In cases where the bug I am chasing is caused by a race condition,
reproducing the problem may take dozens (or more) of attempts.  Again, in
such cases, the pressure is on to collect as much information as possible
on the first run, as it may be very diffucult to re-trigger the race
condition.

With Process Record and Replay once the race condition has been reproduced,
the execution can be reversed and repeated as many time as required to
collect all necessary information.  The race condition is guaranteed to be
present in the replay of the execution since it is simply repeating the
exact execution that was previously recorded.

c) Unknown sequence of events leading to a bug

Sometimes, while testing an application, an unexpected behavior will
be seen.  Unfortunately, the designer often does not recall the exact
events that lead to this behavior and cannot reproduce it.  The situation
is then labelled 'a fluke'.

In some cases, the testing of an application can be done with Process 
Record and Replay enabled.  In such cases, when an application misbehaves,
the events leading to that point have been recorded and can be replayed
immediately and investigated thoroughly.  Bugs can no longer escape
through the 'fluke' door.

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Mon, 4 May 2009 10:32:10 -0400
> From: "Marc Khouzam" <marc.khouzam@ericsson.com>
> Cc: <gdb-patches@sourceware.org>
> 
> These points will not be a surprise to anyone, but I figure 
> they may help get the ball rolling.
> Some of the values that I find in Process Record and Replay are:

Thanks!

Re: Process record and replay checked in to main trunk

[Michael Snyder]

Eli Zaretskii wrote:
>> Date: Sun, 3 May 2009 22:15:34 +0800
>> From: Hui Zhu <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>>> No, I mean description of when this target is useful in real life, and
>>> how you will use it.  In other words, put yourself in a place of
>>> someone who reads the manual about the record/replay target and asks
>>> him/herself "why should I care about this new feature?"  Then try to
>>> answer that question.  And try to answer it so that the reader will
>>> wonder how could she ever get by without this feature before.
>>>
>> I got it.  I will try to deal with it.
> 
> Thanks.
> 
>> I am not a native speaker and poor english ability.
>> Could some people help me with it?
> 
> Don't worry about that.  Just write what you can, and I will take care
> of rephrasing it as needed.
> 
> By gathering bits and pieces, I'm beginning to understand that process
> record/replay is part of our support for ``reversible debugging''.  If
> that is true, would people agree to have a chapter by that name in the
> manual, explaining what is this all about, and to move all the related
> sections into that chapter?

I think that's a good idea.

I also still owe you a NEWS item for the reverse debug commands.

Re: Process record and replay checked in to main trunk

[Hui Zhu]

On Mon, May 4, 2009 at 19:14, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 3 May 2009 21:54:19 +0800
>> From: Hui Zhu <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>> On Fri, May 1, 2009 at 21:27, Eli Zaretskii <eliz@gnu.org> wrote:
>> > It would be nice if i386-tdep.c had some comments about what it takes
>> > for another x86 target to add support for process recording and
>> > replay.  Apologies if it's already described somewhere and I missed
>> > it.
>> >
>> > It looks like all is needed is to define suitable functions for
>> > tdep->i386_intx80_record and tdep->i386_sysenter_record, is that
>> > right?  (If so, why so Linux-centric names?)
>>
>> The intx80 and sysenter function pointers is the interface for
>> i386-os-tdep code to set intx86 insn and sysenter special record
>> functions.
>> Because some os (linux) have special function in intx80 and sysenter
>> (system call).
>>
>> So, in other arch, maybe there will have other interface.  For
>> example, arm will have a swi interface, mips will have a syscall
>> interface.
>
> Right, but I was asking about another _x86_ target, not just any
> target.  Is there anything an i386 target needs to do to get process
> record and replay work, except define suitable i386_intx80_record and
> i386_sysenter_record functions?

Yes, if they use sysenter or intx80 to be syscall.  They need set
these function pointers with themselves.
If some os use another insn to be syscall.  the prec in i386-tdep need
update to support interface for it.

>
>> > just looking at i386_linux_intx80_sysenter_record, I cannot
>> > understand how it succeed to record both the arguments to the syscall
>> > and the return value.  The syscall itself does not happen inside
>> > record_linux_system_call, that just records the syscall parameters and
>> > data buffers, right?  And recording happens _before_ the instruction
>> > being recorded executes, right?  So how come
>> > i386_linux_intx80_sysenter_record can use EAX as the syscall number
>> > and immediately after the call to record_linux_system_call treat the
>> > value of EAX as the value returned by the syscall?  What am I missing
>> > here?
>>
>> This is because all record work will be done before insn execute.
>> Before insn execute, p record parse this insn.  Find out which
>> register and memory will be changed in this insn.  Record the old
>> value of the reg and mem.
>
> Okay, and when will they record the new values of the registers and
> memory affected by the syscall?
>

Prec will not record the new value in forward execute because this
value is in inferior.
When reverse execute, prec wll record the new value and set old value
to inferior.


Thanks,
Hui

Re: Process record and replay checked in to main trunk

[Hui Zhu]

On Mon, May 4, 2009 at 19:17, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 3 May 2009 22:15:34 +0800
>> From: Hui Zhu <teawater@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>> > No, I mean description of when this target is useful in real life, and
>> > how you will use it.  In other words, put yourself in a place of
>> > someone who reads the manual about the record/replay target and asks
>> > him/herself "why should I care about this new feature?"  Then try to
>> > answer that question.  And try to answer it so that the reader will
>> > wonder how could she ever get by without this feature before.
>> >
>>
>> I got it.  I will try to deal with it.
>
> Thanks.
>
>> I am not a native speaker and poor english ability.
>> Could some people help me with it?
>
> Don't worry about that.  Just write what you can, and I will take care
> of rephrasing it as needed.
OK. Thanks.  I will try.

>
> By gathering bits and pieces, I'm beginning to understand that process
> record/replay is part of our support for ``reversible debugging''.  If
> that is true, would people agree to have a chapter by that name in the
> manual, explaining what is this all about, and to move all the related
> sections into that chapter?

This idea is very good for me.

Re: Process record and replay checked in to main trunk

[Hui Zhu]

On Mon, May 4, 2009 at 22:32, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org
>> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Hui Zhu
>> Sent: Sunday, May 03, 2009 10:16 AM
>> To: Eli Zaretskii
>> Cc: gdb-patches@sourceware.org
>> Subject: Re: Process record and replay checked in to main trunk
>>
>> On Sat, May 2, 2009 at 01:55, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Sat, 2 May 2009 01:02:33 +0800
>> >> From: Hui Zhu <teawater@gmail.com>
>> >> Cc: gdb-patches@sourceware.org, pedro@codesourcery.com,
>> >>       marc.khouzam@ericsson.com, msnyder@vmware.com,
>> bauerman@br.ibm.com,
>> >>       mark.kettenis@xs4all.nl
>> >>
>> >> > What I think is still missing from the manual is a few
>> sentences that
>> >> > would explain when this target is useful.  Can you
>> provide such ``war
>> >> > stories''?  I will then add them to the manual.
>> >>
>> >> Which sentences? ``war stories''?
>> >> Do you mean is internal doc?
>> >
>> > No, I mean description of when this target is useful in
>> real life, and
>> > how you will use it.  In other words, put yourself in a place of
>> > someone who reads the manual about the record/replay target and asks
>> > him/herself "why should I care about this new feature?"  Then try to
>> > answer that question.  And try to answer it so that the reader will
>> > wonder how could she ever get by without this feature before.
>> >
>>
>> I got it.  I will try to deal with it.
>>
>> I am not a native speaker and poor english ability.
>> Could some people help me with it?
>
> These points will not be a surprise to anyone, but I figure
> they may help get the ball rolling.
> Some of the values that I find in Process Record and Replay are:
>
> a) Debugging a problem that requires a lot of user input.
>
> Say my software is a graphical application and I get a
> report that a specific long sequence of user-interface operations
> causes a bug.  Fixing the bug requires me to reproduce it by
> repeating the many UI operations until I arrive at the point of
> execution where the bug occurs.  If I have to go over the problematic
> part of the execution multiple times, traditional debugging requires
> me to manually repeat the long sequence of UI steps over and over,
> until I have collected all the necessary information.
>
> With Process Record and Replay, the pressure of obtaining as much
> information as possible in a single run is removed.  If I need to
> collect more information that I originally thought, it is now possible
> to simply reverse the execution up to the point I'm interested in, and
> repeat the execution forward again, collecting the info that was missed.
> The long sequence of UI steps need only be done once.
>
> b) Debugging a race condition
>
> In cases where the bug I am chasing is caused by a race condition,
> reproducing the problem may take dozens (or more) of attempts.  Again, in
> such cases, the pressure is on to collect as much information as possible
> on the first run, as it may be very diffucult to re-trigger the race
> condition.
>
> With Process Record and Replay once the race condition has been reproduced,
> the execution can be reversed and repeated as many time as required to
> collect all necessary information.  The race condition is guaranteed to be
> present in the replay of the execution since it is simply repeating the
> exact execution that was previously recorded.
>
> c) Unknown sequence of events leading to a bug
>
> Sometimes, while testing an application, an unexpected behavior will
> be seen.  Unfortunately, the designer often does not recall the exact
> events that lead to this behavior and cannot reproduce it.  The situation
> is then labelled 'a fluke'.
>
> In some cases, the testing of an application can be done with Process
> Record and Replay enabled.  In such cases, when an application misbehaves,
> the events leading to that point have been recorded and can be replayed
> immediately and investigated thoroughly.  Bugs can no longer escape
> through the 'fluke' door.

Wow.  These cover most of words I want to say.  Thank you very much.  :)
I posted this url to wiki.


Hui

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Tue, 5 May 2009 21:39:50 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org
> 
> On Mon, May 4, 2009 at 19:14, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Sun, 3 May 2009 21:54:19 +0800
> >> From: Hui Zhu <teawater@gmail.com>
> >> Cc: gdb-patches@sourceware.org
> >>
> > Right, but I was asking about another _x86_ target, not just any
> > target.  Is there anything an i386 target needs to do to get process
> > record and replay work, except define suitable i386_intx80_record and
> > i386_sysenter_record functions?
> 
> Yes, if they use sysenter or intx80 to be syscall.  They need set
> these function pointers with themselves.
> If some os use another insn to be syscall.  the prec in i386-tdep need
> update to support interface for it.

But if the i386_intx80_record and i386_sysenter_record are
Linux-specific interfaces, why they are visible in i386-tdep.c, which
is supposed to be common to all i386 targets?

Note that I don't mind so much the _names_, but you seem to say that
these names are somehow magical, and if, for example, syscalls on some
i386 target are entered through Int 31h (say), then there need to be a
separate member in the tdep structure called i386_intx31_record?

> Prec will not record the new value in forward execute because this
> value is in inferior.
> When reverse execute, prec wll record the new value and set old value
> to inferior.

Maybe I'm confused, but does this mean that if I need to replay a
portion of debugging session I need first to reverse-execute all the
recorded instructions until the point where I want to start replaying?

Re: Process record and replay checked in to main trunk

[Mark Kettenis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

> > Date: Tue, 5 May 2009 21:39:50 +0800
> > From: Hui Zhu <teawater@gmail.com>
> > Cc: gdb-patches@sourceware.org
> > 
> > On Mon, May 4, 2009 at 19:14, Eli Zaretskii <eliz@gnu.org> wrote:
> > >> Date: Sun, 3 May 2009 21:54:19 +0800
> > >> From: Hui Zhu <teawater@gmail.com>
> > >> Cc: gdb-patches@sourceware.org
> > >>
> > > Right, but I was asking about another _x86_ target, not just any
> > > target.  Is there anything an i386 target needs to do to get process
> > > record and replay work, except define suitable i386_intx80_record and
> > > i386_sysenter_record functions?
> > 
> > Yes, if they use sysenter or intx80 to be syscall.  They need set
> > these function pointers with themselves.
> > If some os use another insn to be syscall.  the prec in i386-tdep need
> > update to support interface for it.
> 
> But if the i386_intx80_record and i386_sysenter_record are
> Linux-specific interfaces, why they are visible in i386-tdep.c, which
> is supposed to be common to all i386 targets?

As far as I know all open source Unix-like operating systems implement systemcalls using int0x80 amd/or syscall.

Re: Process record and replay checked in to main trunk

[Eli Zaretskii]

> Date: Tue, 5 May 2009 21:32:08 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: teawater@gmail.com, gdb-patches@sourceware.org
> 
> As far as I know all open source Unix-like operating systems implement systemcalls using int0x80 amd/or syscall.

That still isn't general enough to cover every i386 target, is it?

Maybe I'm wrong in assuming that OS specifics should be kept out of
i386-tdep.c.

And I still don't understand why cannot some hypothetical i386 target
to use the _name_ i386_intx80_record to support sycalls that are
entered through an interrupt other than 80h.  Hui seemed to say this
name is reserved for syscalls through Int 80h.

If the name is not special, why not call it i386_syscall_record, for
example?

Re: Process record and replay checked in to main trunk

[Hui Zhu]

Hi Eli,

On Wed, May 6, 2009 at 03:52, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 5 May 2009 21:32:08 +0200 (CEST)
>> From: Mark Kettenis <mark.kettenis@xs4all.nl>
>> CC: teawater@gmail.com, gdb-patches@sourceware.org
>>
>> As far as I know all open source Unix-like operating systems implement systemcalls using int0x80 amd/or syscall.
>
> That still isn't general enough to cover every i386 target, is it?
>

I think it cover most of them.

> Maybe I'm wrong in assuming that OS specifics should be kept out of
> i386-tdep.c.

This just a interface. Any OS that use intx80 and sysenter to do some
special thing (for example system call) will set it.


>
> And I still don't understand why cannot some hypothetical i386 target
> to use the _name_ i386_intx80_record to support sycalls that are
> entered through an interrupt other than 80h.  Hui seemed to say this
> name is reserved for syscalls through Int 80h.
>
> If the name is not special, why not call it i386_syscall_record, for
> example?

Because some os use intx80, others use sysenter.  Linux is special.
Linux 2.4 use intx80, 2.6 use sysenter.


Thanks,
Hui

RE: Process record and replay checked in to main trunk

[Pierre Muller]

Your patch seems to break multi build for cygwin:

If I configure with --enable-targets=all and --enable-64-bits-bfd


gcc -gstabs+ -O0   -I. -I../../purecvs/gdb -I../../purecvs/gdb/common
-I../../pu
recvs/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H
-I../
../purecvs/gdb/../include/opcode -I../../purecvs/gdb/../readline/.. -I../bfd
-I.
./../purecvs/gdb/../bfd -I../../purecvs/gdb/../include -I../libdecnumber
-I../..
/purecvs/gdb/../libdecnumber  -I../../purecvs/gdb/gnulib -Ignulib
-DMI_OUT=1 -D
TUI=1   -Wall -Wdeclaration-after-statement -Wpointer-arith
-Wformat-nonliteral
-Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -o linux-record.o
-MT li
nux-record.o -MMD -MP -MF .deps/linux-record.Tpo
../../purecvs/gdb/linux-record.
c
../../purecvs/gdb/linux-record.c: In function `record_linux_system_call':
../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t
arg
 (arg 2)
../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t
arg
 (arg 2)
../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg
3)
../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg
3)
../../purecvs/gdb/linux-record.c:938: warning: unsigned int format, uint32_t
arg
 (arg 2)
../../purecvs/gdb/linux-record.c:938: warning: unsigned int format, uint32_t
arg
 (arg 2)
../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared (first
use
in this function)
../../purecvs/gdb/linux-record.c:1636: error: (Each undeclared identifier is
rep
orted only once
../../purecvs/gdb/linux-record.c:1636: error: for each function it appears
in.)
../../purecvs/gdb/linux-record.c:1642: error: `F_SETLK64' undeclared (first
use
in this function)
../../purecvs/gdb/linux-record.c:1643: error: `F_SETLKW64' undeclared (first
use
 in this function)
../../purecvs/gdb/linux-record.c:1789: warning: int format, long int arg
(arg 4)

../../purecvs/gdb/linux-record.c:2199: warning: unsigned int format,
uint32_t ar
g (arg 2)
../../purecvs/gdb/linux-record.c:2199: warning: unsigned int format,
uint32_t ar
g (arg 2)
make[1]: *** [linux-record.o] Error 1
make[1]: Leaving directory `/usr/local/src/gdbcvs/multibuild/gdb'
make: *** [all-gdb] Error 2


  Maybe it is out of scope to support reverse debugging of
linux code for remote target, but would it then be possible
to avoid that this source gets compiled?


Pierre Muller
Pascal language support maintainer for GDB


> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Hui Zhu
> Envoyé : Thursday, April 30, 2009 10:02 AM
> À : gdb ml
> Cc : Pedro Alves; Marc Khouzam; Michael Snyder; Thiago Jung Bauermann;
> Eli Zaretskii; Mark Kettenis
> Objet : Process record and replay checked in to main trunk
> 
> Hi guys,
> 
> Process record and replay make gdb can record inferior execute log and
> replay (include reverse debug).
> Now, it support I386-Linux single-thread single-inferior native debug.
> 
> 
> It was checked in today.
> Thanks for evey people that spent time on process record.  Precord
> can't be a part of gdb without your help.  Thank you very much.  :)
> 
> 
> And precord still has a long way to go.  There have a lot of thing need
> to do:
> 
> 1. Support i386 more better.  Now, precord doesn't support mmx insns,
> support fp insns not very well and doesn't support a lot of insns.
> 
> 2. Support more arches.  X86-64 is the first one (linux-record.c).
> MIPS, ARM and so on.
> 
> 3. Support memory free better.  Now, precord just can output a warning
> for memumap.  It can do nothing when there is a sys_brk to free the
> memory.
> I had make a patch to output a warning when there is a sys_brk to free
> the memory and make a plan to make precord can support free memory.
> I will keep work on it.
> 
> 4. Support multi-thread and multi-inferior.
> I remember Pedro make a patch for reverse debug resume.  I think we
> need this patch when multi-inferior check in.
> 
> 5. Make record speed up and need less memory.
> I have made a plan to make p record doesn't record execution log of
> some functions (It can set), for example some functions in glibc.
> 
> 6. Make execution log can dump out to be a file and can replay for next
> time.
> Maybe it can make together with coredump support.  It must be a cool
> function.  :)
> 
> Guys, please work on it if you interesting with some of them.  And
> feel free tell me your ideas and comments.  It will help precord a
> lot.
> 
> 
> Thanks,
> Hui

Re: Process record and replay checked in to main trunk

[Michael Snyder]

Guessing it isn't implemented for 64 bit.

Perhaps we should have a --disable-process-record config option?
If only for a back-up plan?

Pierre Muller wrote:
> Your patch seems to break multi build for cygwin:
> 
> If I configure with --enable-targets=all and --enable-64-bits-bfd
> 
> 
> gcc -gstabs+ -O0   -I. -I../../purecvs/gdb -I../../purecvs/gdb/common
> -I../../pu
> recvs/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H
> -I../
> ../purecvs/gdb/../include/opcode -I../../purecvs/gdb/../readline/.. -I../bfd
> -I.
> ./../purecvs/gdb/../bfd -I../../purecvs/gdb/../include -I../libdecnumber
> -I../..
> /purecvs/gdb/../libdecnumber  -I../../purecvs/gdb/gnulib -Ignulib
> -DMI_OUT=1 -D
> TUI=1   -Wall -Wdeclaration-after-statement -Wpointer-arith
> -Wformat-nonliteral
> -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -o linux-record.o
> -MT li
> nux-record.o -MMD -MP -MF .deps/linux-record.Tpo
> ../../purecvs/gdb/linux-record.
> c
> ../../purecvs/gdb/linux-record.c: In function `record_linux_system_call':
> ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t
> arg
>  (arg 2)
> ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t
> arg
>  (arg 2)
> ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg
> 3)
> ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg
> 3)
> ../../purecvs/gdb/linux-record.c:938: warning: unsigned int format, uint32_t
> arg
>  (arg 2)
> ../../purecvs/gdb/linux-record.c:938: warning: unsigned int format, uint32_t
> arg
>  (arg 2)
> ../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared (first
> use
> in this function)
> ../../purecvs/gdb/linux-record.c:1636: error: (Each undeclared identifier is
> rep
> orted only once
> ../../purecvs/gdb/linux-record.c:1636: error: for each function it appears
> in.)
> ../../purecvs/gdb/linux-record.c:1642: error: `F_SETLK64' undeclared (first
> use
> in this function)
> ../../purecvs/gdb/linux-record.c:1643: error: `F_SETLKW64' undeclared (first
> use
>  in this function)
> ../../purecvs/gdb/linux-record.c:1789: warning: int format, long int arg
> (arg 4)
> 
> ../../purecvs/gdb/linux-record.c:2199: warning: unsigned int format,
> uint32_t ar
> g (arg 2)
> ../../purecvs/gdb/linux-record.c:2199: warning: unsigned int format,
> uint32_t ar
> g (arg 2)
> make[1]: *** [linux-record.o] Error 1
> make[1]: Leaving directory `/usr/local/src/gdbcvs/multibuild/gdb'
> make: *** [all-gdb] Error 2
> 
> 
>   Maybe it is out of scope to support reverse debugging of
> linux code for remote target, but would it then be possible
> to avoid that this source gets compiled?
> 
> 
> Pierre Muller
> Pascal language support maintainer for GDB
> 
> 
>> -----Message d'origine-----
>> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
>> part de Hui Zhu
>> Envoyé : Thursday, April 30, 2009 10:02 AM
>> À : gdb ml
>> Cc : Pedro Alves; Marc Khouzam; Michael Snyder; Thiago Jung Bauermann;
>> Eli Zaretskii; Mark Kettenis
>> Objet : Process record and replay checked in to main trunk
>>
>> Hi guys,
>>
>> Process record and replay make gdb can record inferior execute log and
>> replay (include reverse debug).
>> Now, it support I386-Linux single-thread single-inferior native debug.
>>
>>
>> It was checked in today.
>> Thanks for evey people that spent time on process record.  Precord
>> can't be a part of gdb without your help.  Thank you very much.  :)
>>
>>
>> And precord still has a long way to go.  There have a lot of thing need
>> to do:
>>
>> 1. Support i386 more better.  Now, precord doesn't support mmx insns,
>> support fp insns not very well and doesn't support a lot of insns.
>>
>> 2. Support more arches.  X86-64 is the first one (linux-record.c).
>> MIPS, ARM and so on.
>>
>> 3. Support memory free better.  Now, precord just can output a warning
>> for memumap.  It can do nothing when there is a sys_brk to free the
>> memory.
>> I had make a patch to output a warning when there is a sys_brk to free
>> the memory and make a plan to make precord can support free memory.
>> I will keep work on it.
>>
>> 4. Support multi-thread and multi-inferior.
>> I remember Pedro make a patch for reverse debug resume.  I think we
>> need this patch when multi-inferior check in.
>>
>> 5. Make record speed up and need less memory.
>> I have made a plan to make p record doesn't record execution log of
>> some functions (It can set), for example some functions in glibc.
>>
>> 6. Make execution log can dump out to be a file and can replay for next
>> time.
>> Maybe it can make together with coredump support.  It must be a cool
>> function.  :)
>>
>> Guys, please work on it if you interesting with some of them.  And
>> feel free tell me your ideas and comments.  It will help precord a
>> lot.
>>
>>
>> Thanks,
>> Hui
> 

Re: Process record and replay checked in to main trunk

[Pedro Alves]

On Thursday 07 May 2009 23:43:13, Michael Snyder wrote:
> Guessing it isn't implemented for 64 bit.

I don't think that's the problem here.  Cygwin is 32-bit, and has 32-bit
ints.

> ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t
> arg

> ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg

Better use casts, or use plongest/pulongest/hex_string where appropriate?

> Perhaps we should have a --disable-process-record config option?
> If only for a back-up plan?

I think that would be more work than fixing this properly.  :-)

> ../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared (first
> use
> in this function)

There are a bunch of RECORD_* macros defined on top of linux-record.c
to replace contants like these.  E.g., RECORD_Q_GETFMT.  Looks like
this case was just missed.

-- 
Pedro Alves

Re: Process record and replay checked in to main trunk

[Hui Zhu]

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

Hi Pierre,

I make a patch to fix this bug, but I don't have cygwin.

Could you please help me test this patch in cygwin?

Thanks,
Hui

On Fri, May 8, 2009 at 07:06, Pedro Alves <pedro@codesourcery.com> wrote:
> On Thursday 07 May 2009 23:43:13, Michael Snyder wrote:
>> Guessing it isn't implemented for 64 bit.
>
> I don't think that's the problem here.  Cygwin is 32-bit, and has 32-bit
> ints.
>
>> ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t
>> arg
>
>> ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg
>
> Better use casts, or use plongest/pulongest/hex_string where appropriate?
>
>> Perhaps we should have a --disable-process-record config option?
>> If only for a back-up plan?
>
> I think that would be more work than fixing this properly.  :-)
>
>> ../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared (first
>> use
>> in this function)
>
> There are a bunch of RECORD_* macros defined on top of linux-record.c
> to replace contants like these.  E.g., RECORD_Q_GETFMT.  Looks like
> this case was just missed.
>
> --
> Pedro Alves
>

[-- Attachment #2: fix-prec-cygwin-build-error.txt --]
[-- Type: text/plain, Size: 4434 bytes --]

---
 i386-linux-tdep.c |   14 ++++++++++++++
 linux-record.c    |   28 +++++++++++++---------------
 linux-record.h    |    7 +++++++
 3 files changed, 34 insertions(+), 15 deletions(-)

--- a/i386-linux-tdep.c
+++ b/i386-linux-tdep.c
@@ -586,6 +586,14 @@ static int i386_linux_sc_reg_offset[] =
 #define I386_LINUX_RECORD_IOCTL_TIOCSHAYESESP		0x545F
 #define I386_LINUX_RECORD_IOCTL_FIOQSIZE		0x5460
 
+/* The values of the second argument of system call "sys_fcntl"
+   and "sys_fcntl64".  The values of these macros were obtained from
+   Linux Kernel source.  */
+#define I386_LINUX_RECORD_FCNTL_F_GETLK			5
+#define I386_LINUX_RECORD_FCNTL_F_GETLK64		12
+#define I386_LINUX_RECORD_FCNTL_F_SETLK64		13
+#define I386_LINUX_RECORD_FCNTL_F_SETLKW64		14
+
 static void
 i386_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
@@ -781,6 +789,12 @@ i386_linux_init_abi (struct gdbarch_info
     I386_LINUX_RECORD_IOCTL_TIOCSHAYESESP;
   i386_linux_record_tdep.ioctl_FIOQSIZE = I386_LINUX_RECORD_IOCTL_FIOQSIZE;
 
+  i386_linux_record_tdep.fcntl_F_GETLK = I386_LINUX_RECORD_FCNTL_F_GETLK;
+  i386_linux_record_tdep.fcntl_F_GETLK64 = I386_LINUX_RECORD_FCNTL_F_GETLK64;
+  i386_linux_record_tdep.fcntl_F_SETLK64 = I386_LINUX_RECORD_FCNTL_F_SETLK64;
+  i386_linux_record_tdep.fcntl_F_SETLKW64 =
+    I386_LINUX_RECORD_FCNTL_F_SETLKW64;
+
   i386_linux_record_tdep.arg1 = I386_EBX_REGNUM;
   i386_linux_record_tdep.arg2 = I386_ECX_REGNUM;
   i386_linux_record_tdep.arg3 = I386_EDX_REGNUM;
--- a/linux-record.c
+++ b/linux-record.c
@@ -394,7 +394,7 @@ record_linux_system_call (int num, struc
 	{
 	  printf_unfiltered (_("Process record and replay target doesn't "
 			       "support ioctl request 0x%08x.\n"),
-			     tmpu32);
+			     (int)tmpu32);
 	  return 1;
 	}
       break;
@@ -404,7 +404,7 @@ record_linux_system_call (int num, struc
       /* XXX */
       regcache_raw_read (regcache, tdep->arg2, (gdb_byte *) & tmpu32);
     sys_fcntl:
-      if (tmpu32 == F_GETLK)
+      if (tmpu32 == tdep->fcntl_F_GETLK)
 	{
 	  regcache_raw_read (regcache, tdep->arg3,
 			     (gdb_byte *) & tmpu32);
@@ -626,7 +626,7 @@ record_linux_system_call (int num, struc
 		    "It will free the memory addr = 0x%s len = %d.  "
 		    "It will make record target get error.  "
 		    "Do you want to stop the program?"),
-		  paddr_nz (tmpu32), len);
+		  paddr_nz (tmpu32), (int)len);
 	target_terminal_inferior ();
 	if (q)
 	  return 1;
@@ -935,7 +935,7 @@ record_linux_system_call (int num, struc
 	default:
 	  printf_unfiltered (_("Process record and replay target "
 			       "doesn't support socketcall call 0x%08x\n"),
-			     tmpu32);
+			     (int)tmpu32);
 	  return -1;
 	  break;
 	}
@@ -1631,20 +1631,17 @@ record_linux_system_call (int num, struc
       /* sys_fcntl64 */
     case 221:
       regcache_raw_read (regcache, tdep->arg2, (gdb_byte *) & tmpu32);
-      switch (tmpu32)
-	{
-	case F_GETLK64:
+      if (tmpu32 == tdep->fcntl_F_GETLK64)
+        {
 	  regcache_raw_read (regcache, tdep->arg3,
 			     (gdb_byte *) & tmpu32);
 	  if (record_arch_list_add_mem (tmpu32, tdep->size_flock64))
 	    return -1;
-	  break;
-	case F_SETLK64:
-	case F_SETLKW64:
-	  break;
-	default:
+	}
+      else if (tmpu32 != tdep->fcntl_F_SETLK64
+	       && tmpu32 != tdep->fcntl_F_SETLKW64)
+        {
 	  goto sys_fcntl;
-	  break;
 	}
       break;
 
@@ -1786,7 +1783,8 @@ record_linux_system_call (int num, struc
 		fprintf_unfiltered (gdb_stdlog,
 				    "Process record: error reading memory "
 				    "at addr = 0x%s len = %d.\n",
-				    paddr_nz (tmpu32), nr * tdep->size_int);
+				    paddr_nz (tmpu32),
+				    (int)(nr * tdep->size_int));
 	      return -1;
 	    }
 	  for (i = 0; i < nr; i++)
@@ -2196,7 +2194,7 @@ record_linux_system_call (int num, struc
     default:
       printf_unfiltered (_("Process record and replay target doesn't "
 			   "support syscall number 0x%08x\n"),
-			 tmpu32);
+			 (int)tmpu32);
       return -1;
       break;
     }
--- a/linux-record.h
+++ b/linux-record.h
@@ -158,6 +158,13 @@ struct linux_record_tdep
   int ioctl_TIOCSHAYESESP;
   int ioctl_FIOQSIZE;
 
+  /* The values of the second argument of system call "sys_fcntl"
+     and "sys_fcntl64".  */
+  int fcntl_F_GETLK;
+  int fcntl_F_GETLK64;
+  int fcntl_F_SETLK64;
+  int fcntl_F_SETLKW64;
+
   /* The number of the registers that are used as the arguments of
      a system call.  */
   int arg1;

RE: Process record and replay checked in to main trunk

[Pierre Muller]

I tested this both in 32bit and 64bit CORE_ADDR length.

I can confirm that cygwin compilation is fixed in both
cases with that patch and hope it will be approved
rapidly.

  Thanks, Hui.


Pierre Muller
Pascal language support maintainer for GDB




> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Hui Zhu
> Envoyé : Friday, May 08, 2009 7:12 AM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org; Michael Snyder; Pedro Alves
> Objet : Re: Process record and replay checked in to main trunk
> 
> Hi Pierre,
> 
> I make a patch to fix this bug, but I don't have cygwin.
> 
> Could you please help me test this patch in cygwin?
> 
> Thanks,
> Hui
> 
> On Fri, May 8, 2009 at 07:06, Pedro Alves <pedro@codesourcery.com>
> wrote:
> > On Thursday 07 May 2009 23:43:13, Michael Snyder wrote:
> >> Guessing it isn't implemented for 64 bit.
> >
> > I don't think that's the problem here.  Cygwin is 32-bit, and has
> > 32-bit ints.
> >
> >> ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format,
> >> uint32_t arg
> >
> >> ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t
> >> arg (arg
> >
> > Better use casts, or use plongest/pulongest/hex_string where
> appropriate?
> >
> >> Perhaps we should have a --disable-process-record config option?
> >> If only for a back-up plan?
> >
> > I think that would be more work than fixing this properly.  :-)
> >
> >> ../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared
> >> (first use in this function)
> >
> > There are a bunch of RECORD_* macros defined on top of linux-record.c
> > to replace contants like these.  E.g., RECORD_Q_GETFMT.  Looks like
> > this case was just missed.
> >
> > --
> > Pedro Alves
> >

Re: Process record and replay checked in to main trunk

[Hui Zhu]

Thanks Pierre.  You help me a lot.  :)

Hui

On Fri, May 8, 2009 at 20:11, Pierre Muller <muller@ics.u-strasbg.fr> wrote:
> I tested this both in 32bit and 64bit CORE_ADDR length.
>
> I can confirm that cygwin compilation is fixed in both
> cases with that patch and hope it will be approved
> rapidly.
>
>  Thanks, Hui.
>
>
> Pierre Muller
> Pascal language support maintainer for GDB
>
>
>
>
>> -----Message d'origine-----
>> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
>> owner@sourceware.org] De la part de Hui Zhu
>> Envoyé : Friday, May 08, 2009 7:12 AM
>> À : Pierre Muller
>> Cc : gdb-patches@sourceware.org; Michael Snyder; Pedro Alves
>> Objet : Re: Process record and replay checked in to main trunk
>>
>> Hi Pierre,
>>
>> I make a patch to fix this bug, but I don't have cygwin.
>>
>> Could you please help me test this patch in cygwin?
>>
>> Thanks,
>> Hui
>>
>> On Fri, May 8, 2009 at 07:06, Pedro Alves <pedro@codesourcery.com>
>> wrote:
>> > On Thursday 07 May 2009 23:43:13, Michael Snyder wrote:
>> >> Guessing it isn't implemented for 64 bit.
>> >
>> > I don't think that's the problem here.  Cygwin is 32-bit, and has
>> > 32-bit ints.
>> >
>> >> ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format,
>> >> uint32_t arg
>> >
>> >> ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t
>> >> arg (arg
>> >
>> > Better use casts, or use plongest/pulongest/hex_string where
>> appropriate?
>> >
>> >> Perhaps we should have a --disable-process-record config option?
>> >> If only for a back-up plan?
>> >
>> > I think that would be more work than fixing this properly.  :-)
>> >
>> >> ../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared
>> >> (first use in this function)
>> >
>> > There are a bunch of RECORD_* macros defined on top of linux-record.c
>> > to replace contants like these.  E.g., RECORD_Q_GETFMT.  Looks like
>> > this case was just missed.
>> >
>> > --
>> > Pedro Alves
>> >
>
>