GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[teawater]

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

Hi All,

The attachment is a patch for the GDB-6.6 that will add two commands
("record" and "reverse") and a new target "record" to the GDB-6.6.

The command "record" can record running message such as the program pc
register value and some frame message to a record file that default
name is "now.rec".

The target "record" can open this record file and debug the program.
And if the current target is the "record", you can use command
"reverse" set debug to the reverse debug mode. If you set GDB to the
reverse debug mode. The program will reverse run. Most of GDB command
such as "step", "next" and "breakpoint" can be use in this mode.

Maybe the record function can make GDB debug real time program more
easy than before because you can record all the running message when
the real time program cannot be interrupt and debug it after it was
running.

Now, the record function is not very complete. In the future, I will
make it more useful such as record all the register value, record the
memory change and make it only record the running message of some
program code.
Please give me your thought about the "record". Thanks a lot.

To make and install the GDB record target 0.0.1 with GDB-6.6:
tar vxjf gdb-6.6.tar.bz2
bunzip2 gdb-6.6-record-0.0.1.patch.bz2
patch -p0 < gdb-6.6-record-0.0.1.patch
mkdir bgdb
cd bgdb
../gdb-6.6/configure
make
make install

To use the GDB record function:
cat 1.c
void
cool ()
{
        printf ("123");
}
int
main(int argc,char *argv[],char *envp[])
{
        int     a = 0;

        printf ("1\n");

        cool ();

        a = 1;
        a += 2;

        return (0);
}
gcc -g 1.c
./gdb a.out
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
/home/qwang/rec/bgdb/gdb/.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) b main
Breakpoint 1 at 0x804836c: file 1.c, line 9.
(gdb) r
Starting program: /home/qwang/rec/bgdb/gdb/a.out

Breakpoint 1, main (argc=
During symbol reading, incomplete CFI data; unspecified registers
(e.g., eax) at 0x804837b.
1, argv=0xbfffdae4, envp=0xbfffdaec) at 1.c:9
9               int     a = 0;
(gdb) rec
Record the paogram running message to the file "now.rec".
1
During symbol reading, incomplete CFI data; DW_CFA_restore unspecified
register ebx (#3) at 0x0075df5f.
123
Program exited normally.
(gdb) quit
./gdb a.out
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
/home/qwang/rec/bgdb/gdb/.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) target rec
Record the paogram running message to the file "now.rec".
main (argc=Cannot access memory at address 0x8
) at 1.c:9
9               int     a = 0;
(gdb) n
11              printf ("1\n");
(gdb)
13              cool ();
(gdb)
15              a = 1;
(gdb) c
Continuing.
0x00738b09 in ?? ()
(gdb) rev
GDB is set to reverse debug mode.
(gdb) b 16
Breakpoint 1 at 0x804838f: file 1.c, line 16.
(gdb) c
Continuing.

Breakpoint 1, main (argc=Cannot access memory at address 0x8
) at 1.c:16
16              a += 2;
(gdb) n
15              a = 1;
(gdb) n
13              cool ();
(gdb) rev
GDB is set to normal debug mode.
(gdb) s
cool () at 1.c:4
4               printf ("123");
(gdb) n
5       }
(gdb)
main (argc=Cannot access memory at address 0x8
) at 1.c:15
15              a = 1;
(gdb) rev
GDB is set to reverse debug mode.
(gdb) s
cool () at 1.c:4
4               printf ("123");
(gdb) s
0x08048347      3       {
(gdb)
main (argc=Cannot access memory at address 0x8
) at 1.c:13
13              cool ();
(gdb) quit
The program is running.  Exit anyway? (y or n) y



Thanks,
teawater

[-- Attachment #2: gdb-6.6-record-0.0.1.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 6836 bytes --]

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Eli Zaretskii]

> Date: Fri, 10 Aug 2007 17:31:51 +0800
> From: teawater <teawater@gmail.com>
> 
> The attachment is a patch for the GDB-6.6 that will add two commands
> ("record" and "reverse") and a new target "record" to the GDB-6.6.
> 
> The command "record" can record running message such as the program pc
> register value and some frame message to a record file that default
> name is "now.rec".
> 
> The target "record" can open this record file and debug the program.
> And if the current target is the "record", you can use command
> "reverse" set debug to the reverse debug mode. If you set GDB to the
> reverse debug mode. The program will reverse run. Most of GDB command
> such as "step", "next" and "breakpoint" can be use in this mode.

I think this is a very good feature.  Thanks!

> Please give me your thought about the "record". Thanks a lot.

I have some comments on the patch.  (Btw, in the future, please send
the patch in the body of the message as text, do not compress and
attach it as a binary attachment, as that makes reviewing the patch
less convenient.)

> +/*teawater rec begin----------------------------------------------------------*/
> [...]
> +/*teawater rec end------------------------------------------------------------*/

These markings have to go.

> -		    error (_("Cannot find bounds of current function"));
> +		    error (_("Cannot find bounds of current function1"));
 
> -		error (_("Cannot find bounds of current function"));
> +		error (_("Cannot find bounds of current function2"));

These changes are superfluous and should not be part of your patch.
 
> +      if (stop_signal == TARGET_SIGNAL_TRAP) {
> +		if (gdb_is_reverse) {
> +			ecs->random_signal = 0;
> +		}
> +		else {
> +			ecs->random_signal
> +			  = !(bpstat_explains_signal (stop_bpstat)
> +			      || trap_expected
> +			      || (step_range_end && step_resume_breakpoint == NULL));
> +		}
> +	}

This is not the GNU style of formatting C blocks.  Please use the
style the rest of GDB uses.  The indentation is also incorrect (GNU
style uses 2 columns for each level, not 4).

> +static __inline__ void __list_add(struct list_head * new,

I don't think we can use __inline__ without catering to compilers that
don't support it.

> +#include <stdint.h>

Can we portably depend on stdint.h being available?  I think we
cannot.  Can we do without it?

> +#include <termios.h>

Why do you need termios.h here?

> +#include <netinet/in.h>

Is this really needed?

> +	//open file
> +	if (name) {
> +		printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", name);
> +		record_fd = open (name, O_RDONLY);
> +	}
> +	else {
> +		printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", record_DEF_FILE);
> +		record_fd = open (record_DEF_FILE, O_RDONLY);
> +	}

You need to open the file with O_BINARY, because otherwise file I/O to
the recording file will not work on MS-Windows.

> +		printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", name);
> [...]
> +		error ("Get size of file error.");

Please make all your messages translatable, by enclosing them in
`_()', like we do elsewhere in GDB.

> +	//mmap record_mem
> +	record_mem = mmap (0, record_mem_size, PROT_READ, MAP_FILE | MAP_SHARED, record_fd, 0);
> +	if (record_mem == (caddr_t)-1) {
> +		record_close (0);
> +		error ("Mmap file is error.");
> +	}

Why do we need mmap here? it's not universally supported.  Can't we
just read() the file into memory?

> +		struct sigaction	act, old_act;
> +
> +		record_get_sig = 0;
> +		act.sa_handler = record_sig_handler;
> +		act.sa_mask = record_maskall;
> +		act.sa_flags = SA_RESTART;
> +		if (sigaction (SIGINT, &act, &old_act)) {
> +			perror_with_name ("sigaction");
> +		}

I don't think we can portably use sigaction here.

> +		printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", args);
                                               ^^^^^^^
Please spell-check your comments and strings, there are quite a few
misspellings and incorrect usage of English.

> +		fd = open (args, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

I think this needs O_BINARY.

> +	add_com ("record", class_obscure, record_to_file, _("Record registers valut to file."));
> +	add_com ("rec", class_obscure, record_to_file, _("Record registers valut to file."));
> +	add_com ("reverse", class_obscure, set_gdb_is_reverse, _("Set GDB to the reverse debug mode or the normal debug mode."));
> +	add_com ("rev", class_obscure, set_gdb_is_reverse, _("Set GDB to the reverse debug mode or the normal debug mode."));
> +}

These commands need to be described in the user manual.  So, if your
patch is accepted, please send a patch for the manual to accompany it.

Thanks for working on this.

RE: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Dave Korn]

On 10 August 2007 15:41, Eli Zaretskii wrote:

> I have some comments on the patch.  (Btw, in the future, please send
> the patch in the body of the message as text, do not compress and
> attach it as a binary attachment, as that makes reviewing the patch
> less convenient.)

  Less convenient than having to manually unwrap wrapped lines before you can
apply it?  I find that sending as an uncompressed plaintext attachment gets
the best of both worlds.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> +static __inline__ void __list_add(struct list_head * new,

Identifiers starting with __ are reserved for the implementation.

>> +	//mmap record_mem

C99 features cannot be used yet in GDB.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Eli Zaretskii]

> From: "Dave Korn" <dave.korn@artimi.com>
> Cc: <gdb@sources.redhat.com>
> Date: Fri, 10 Aug 2007 15:53:47 +0100
> 
> On 10 August 2007 15:41, Eli Zaretskii wrote:
> 
> > I have some comments on the patch.  (Btw, in the future, please send
> > the patch in the body of the message as text, do not compress and
> > attach it as a binary attachment, as that makes reviewing the patch
> > less convenient.)
> 
>   Less convenient than having to manually unwrap wrapped lines before you can
> apply it?

No one said that sending patches as regular text necessarily implies
the lines will be wrapped.

> I find that sending as an uncompressed plaintext attachment gets
> the best of both worlds.

I only want a single world: the one where text can be read without
jumping through the hoops.

RE: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Dave Korn]

On 10 August 2007 17:51, Eli Zaretskii wrote:

>> From: "Dave Korn" <dave.korn@artimi.com>
>> Cc: <gdb@sources.redhat.com>
>> Date: Fri, 10 Aug 2007 15:53:47 +0100
>> 
>> On 10 August 2007 15:41, Eli Zaretskii wrote:
>> 
>>> I have some comments on the patch.  (Btw, in the future, please send
>>> the patch in the body of the message as text, do not compress and
>>> attach it as a binary attachment, as that makes reviewing the patch
>>> less convenient.)
>> 
>>   Less convenient than having to manually unwrap wrapped lines before you
>> can apply it?
> 
> No one said that sending patches as regular text necessarily implies
> the lines will be wrapped.

  Well, if the sender switches off wrapping, you'll find that the patch is
easy to read but the entire body of the sender's message comes out as one long
line.

>> I find that sending as an uncompressed plaintext attachment gets
>> the best of both worlds.
> 
> I only want a single world: the one where text can be read without
> jumping through the hoops.

  As far as I know, mailers haven't made anyone "jump through hoops" to read
attachments since about 1981...


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 >> Less convenient than having to manually unwrap wrapped lines
 >> before you can apply it?

 Eli> No one said that sending patches as regular text necessarily
 Eli> implies the lines will be wrapped.

No, for some mailers it doesn't -- but for others it does.

 >> I find that sending as an uncompressed plaintext attachment gets
 >> the best of both worlds.

 Eli> I only want a single world: the one where text can be read
 Eli> without jumping through the hoops.

Attaching a text/plain should do that.

	  paul

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Daniel Jacobowitz]

On Fri, Aug 10, 2007 at 05:31:51PM +0800, teawater wrote:
> Hi All,
> 
> The attachment is a patch for the GDB-6.6 that will add two commands
> ("record" and "reverse") and a new target "record" to the GDB-6.6.
> 
> The command "record" can record running message such as the program pc
> register value and some frame message to a record file that default
> name is "now.rec".
> 
> The target "record" can open this record file and debug the program.
> And if the current target is the "record", you can use command
> "reverse" set debug to the reverse debug mode. If you set GDB to the
> reverse debug mode. The program will reverse run. Most of GDB command
> such as "step", "next" and "breakpoint" can be use in this mode.
> 
> Maybe the record function can make GDB debug real time program more
> easy than before because you can record all the running message when
> the real time program cannot be interrupt and debug it after it was
> running.

I took a look at your patch.  The record command single steps the
program until it exits, right?  That will not be very useful for real
time programs, because it will be extraordinarily slow the first time.

You might want to take a look at my paper in this year's GCC Summit
proceedings:

  http://gcc.gnu.org/wiki/HomePage?action=AttachFile&do=get&target=GCC2007-Proceedings.pdf

We'll be publishing the code for "reverse-step" using qemu soon.
We're not trying to hold on to it, especially - just haven't found the
time yet to submit it.  This is basically similar to what you've done,
except higher performance.

Actually, your work also reminds me of Amber:
  http://weblogs.mozillazine.org/roc/archives/2006/12/more_about_ambe.html

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[teawater]

Thanks a lot to your comments. I will deal with it.

On 8/10/07, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Fri, 10 Aug 2007 17:31:51 +0800
> > From: teawater <teawater@gmail.com>
> >
> > The attachment is a patch for the GDB-6.6 that will add two commands
> > ("record" and "reverse") and a new target "record" to the GDB-6.6.
> >
> > The command "record" can record running message such as the program pc
> > register value and some frame message to a record file that default
> > name is "now.rec".
> >
> > The target "record" can open this record file and debug the program.
> > And if the current target is the "record", you can use command
> > "reverse" set debug to the reverse debug mode. If you set GDB to the
> > reverse debug mode. The program will reverse run. Most of GDB command
> > such as "step", "next" and "breakpoint" can be use in this mode.
>
> I think this is a very good feature.  Thanks!
>
> > Please give me your thought about the "record". Thanks a lot.
>
> I have some comments on the patch.  (Btw, in the future, please send
> the patch in the body of the message as text, do not compress and
> attach it as a binary attachment, as that makes reviewing the patch
> less convenient.)
>
> > +/*teawater rec begin----------------------------------------------------------*/
> > [...]
> > +/*teawater rec end------------------------------------------------------------*/
>
> These markings have to go.
>
> > -                 error (_("Cannot find bounds of current function"));
> > +                 error (_("Cannot find bounds of current function1"));
>
> > -             error (_("Cannot find bounds of current function"));
> > +             error (_("Cannot find bounds of current function2"));
>
> These changes are superfluous and should not be part of your patch.
>
> > +      if (stop_signal == TARGET_SIGNAL_TRAP) {
> > +             if (gdb_is_reverse) {
> > +                     ecs->random_signal = 0;
> > +             }
> > +             else {
> > +                     ecs->random_signal
> > +                       = !(bpstat_explains_signal (stop_bpstat)
> > +                           || trap_expected
> > +                           || (step_range_end && step_resume_breakpoint == NULL));
> > +             }
> > +     }
>
> This is not the GNU style of formatting C blocks.  Please use the
> style the rest of GDB uses.  The indentation is also incorrect (GNU
> style uses 2 columns for each level, not 4).
>
> > +static __inline__ void __list_add(struct list_head * new,
>
> I don't think we can use __inline__ without catering to compilers that
> don't support it.
>
> > +#include <stdint.h>
>
> Can we portably depend on stdint.h being available?  I think we
> cannot.  Can we do without it?
>
> > +#include <termios.h>
>
> Why do you need termios.h here?
>
> > +#include <netinet/in.h>
>
> Is this really needed?
>
> > +     //open file
> > +     if (name) {
> > +             printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", name);
> > +             record_fd = open (name, O_RDONLY);
> > +     }
> > +     else {
> > +             printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", record_DEF_FILE);
> > +             record_fd = open (record_DEF_FILE, O_RDONLY);
> > +     }
>
> You need to open the file with O_BINARY, because otherwise file I/O to
> the recording file will not work on MS-Windows.
>
> > +             printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", name);
> > [...]
> > +             error ("Get size of file error.");
>
> Please make all your messages translatable, by enclosing them in
> `_()', like we do elsewhere in GDB.
>
> > +     //mmap record_mem
> > +     record_mem = mmap (0, record_mem_size, PROT_READ, MAP_FILE | MAP_SHARED, record_fd, 0);
> > +     if (record_mem == (caddr_t)-1) {
> > +             record_close (0);
> > +             error ("Mmap file is error.");
> > +     }
>
> Why do we need mmap here? it's not universally supported.  Can't we
> just read() the file into memory?
>
> > +             struct sigaction        act, old_act;
> > +
> > +             record_get_sig = 0;
> > +             act.sa_handler = record_sig_handler;
> > +             act.sa_mask = record_maskall;
> > +             act.sa_flags = SA_RESTART;
> > +             if (sigaction (SIGINT, &act, &old_act)) {
> > +                     perror_with_name ("sigaction");
> > +             }
>
> I don't think we can portably use sigaction here.
>
> > +             printf_unfiltered ("Record the paogram running message to the file \"%s\".\n", args);
>                                                ^^^^^^^
> Please spell-check your comments and strings, there are quite a few
> misspellings and incorrect usage of English.
>
> > +             fd = open (args, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
>
> I think this needs O_BINARY.
>
> > +     add_com ("record", class_obscure, record_to_file, _("Record registers valut to file."));
> > +     add_com ("rec", class_obscure, record_to_file, _("Record registers valut to file."));
> > +     add_com ("reverse", class_obscure, set_gdb_is_reverse, _("Set GDB to the reverse debug mode or the normal debug mode."));
> > +     add_com ("rev", class_obscure, set_gdb_is_reverse, _("Set GDB to the reverse debug mode or the normal debug mode."));
> > +}
>
> These commands need to be described in the user manual.  So, if your
> patch is accepted, please send a patch for the manual to accompany it.
>
> Thanks for working on this.
>

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[teawater]

On 8/11/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Fri, Aug 10, 2007 at 05:31:51PM +0800, teawater wrote:
> > Hi All,
> >
> > The attachment is a patch for the GDB-6.6 that will add two commands
> > ("record" and "reverse") and a new target "record" to the GDB-6.6.
> >
> > The command "record" can record running message such as the program pc
> > register value and some frame message to a record file that default
> > name is "now.rec".
> >
> > The target "record" can open this record file and debug the program.
> > And if the current target is the "record", you can use command
> > "reverse" set debug to the reverse debug mode. If you set GDB to the
> > reverse debug mode. The program will reverse run. Most of GDB command
> > such as "step", "next" and "breakpoint" can be use in this mode.
> >
> > Maybe the record function can make GDB debug real time program more
> > easy than before because you can record all the running message when
> > the real time program cannot be interrupt and debug it after it was
> > running.
>
> I took a look at your patch.  The record command single steps the
> program until it exits, right?  That will not be very useful for real
> time programs, because it will be extraordinarily slow the first time.
>

The CPU speed is more and more high.
BTW:This command is not very complete. I will make record can only
record a part of code.

> You might want to take a look at my paper in this year's GCC Summit
> proceedings:
>
>   http://gcc.gnu.org/wiki/HomePage?action=AttachFile&do=get&target=GCC2007-Proceedings.pdf
>
> We'll be publishing the code for "reverse-step" using qemu soon.
> We're not trying to hold on to it, especially - just haven't found the
> time yet to submit it.  This is basically similar to what you've done,
> except higher performance.
>

The user need install a QEMU first?
The record can work with host debug and the other target such as sim,
remote and don't need other software.
 BTW: I think if the user want reverse execute to the real past status
of program, record all of the running message is the only way. Because
a lot of thing cannot be reverse execute such a system call. If the
program write some message to a file, howto reverse execute it? Remove
this message from the fire?

> Actually, your work also reminds me of Amber:
>   http://weblogs.mozillazine.org/roc/archives/2006/12/more_about_ambe.html
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Eli Zaretskii]

> Date: Fri, 10 Aug 2007 13:35:42 -0400
> From: Paul Koning <pkoning@equallogic.com>
> Cc: dave.korn@artimi.com,
>     teawater@gmail.com,
>     gdb@sources.redhat.com
> 
>  Eli> I only want a single world: the one where text can be read
>  Eli> without jumping through the hoops.
> 
> Attaching a text/plain should do that.

Fine with me.

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Eli Zaretskii]

> From: "Dave Korn" <dave.korn@artimi.com>
> Cc: <teawater@gmail.com>,
> 	<gdb@sources.redhat.com>
> Date: Fri, 10 Aug 2007 18:24:42 +0100
> 
>   As far as I know, mailers haven't made anyone "jump through hoops" to read
> attachments since about 1981...

It wasn't just an attachment, it was bz2-compressed.

RE: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Dave Korn]

On 11 August 2007 10:37, Eli Zaretskii wrote:

>> From: "Dave Korn" <dave.korn@artimi.com>
>> Cc: <teawater@gmail.com>,
>> 	<gdb@sources.redhat.com>
>> Date: Fri, 10 Aug 2007 18:24:42 +0100
>> 
>>   As far as I know, mailers haven't made anyone "jump through hoops" to
>> read attachments since about 1981...
> 
> It wasn't just an attachment, it was bz2-compressed.

  Agreed there, that's a nuisance; I did specify "sending as an uncompressed
plaintext attachment".  Hopefully pretty much all mailers around these days
have no trouble launching an external editor for a plaintext attachment!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Daniel Jacobowitz]

On Sat, Aug 11, 2007 at 09:37:11AM +0800, teawater wrote:
>  BTW: I think if the user want reverse execute to the real past status of
> program, record all of the running message is the only way. Because a lot of
> thing cannot be reverse execute such a system call. If the program write
> some message to a file, howto reverse execute it? Remove this message from
> the fire?

You may want to read the paper, where I discuss this :-)  The current
implementation records system calls, a future version may indeed
undo output.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support Reversible Debugging)

[Robert Bu]

> ------------------------------------------------------------------------
>
> 主题:
> Re: GDB record target 0.0.1 for GDB-6.6 release (It make GDB support
> Reversible Debugging)
> 发件人:
> Daniel Jacobowitz <drow@false.org>
> 日期:
> Fri, 10 Aug 2007 14:18:17 -0400
> 收件人:
> teawater <teawater@gmail.com>
>
> 收件人:
> teawater <teawater@gmail.com>
> 抄送:
> gdb@sources.redhat.com
>
>
> On Fri, Aug 10, 2007 at 05:31:51PM +0800, teawater wrote:
>> Hi All,
>>
>> The attachment is a patch for the GDB-6.6 that will add two commands
>> ("record" and "reverse") and a new target "record" to the GDB-6.6.
>>
>> The command "record" can record running message such as the program pc
>> register value and some frame message to a record file that default
>> name is "now.rec".
>>
>> The target "record" can open this record file and debug the program.
>> And if the current target is the "record", you can use command
>> "reverse" set debug to the reverse debug mode. If you set GDB to the
>> reverse debug mode. The program will reverse run. Most of GDB command
>> such as "step", "next" and "breakpoint" can be use in this mode.
>>
>> Maybe the record function can make GDB debug real time program more
>> easy than before because you can record all the running message when
>> the real time program cannot be interrupt and debug it after it was
>> running.
>
> I took a look at your patch.  The record command single steps the
> program until it exits, right?  That will not be very useful for real
> time programs, because it will be extraordinarily slow the first time.
>
> You might want to take a look at my paper in this year's GCC Summit
> proceedings:
>
>   http://gcc.gnu.org/wiki/HomePage?action=AttachFile&do=get&target=GCC2007-Proceedings.pdf
>
> We'll be publishing the code for "reverse-step" using qemu soon.

The qemu method is appropriate for native-debugging. However, it's
really not possible for remote-debugging, in which case the mothod of
this patch may apply if we can put up with the poor performance.

> We're not trying to hold on to it, especially - just haven't found the
> time yet to submit it.  This is basically similar to what you've done,
> except higher performance.
>
> Actually, your work also reminds me of Amber:
>   http://weblogs.mozillazine.org/roc/archives/2006/12/more_about_ambe.html
>
>
>

robert