Hi all,

The old version of GDB record cannot show the value of the variable
because it doesn't record the memory change. GDB record target 0.1.0
disassemble the instruction that will be executed to get which memory
and register will be changed and record them to record all the program
running message.
Because need add disassemble the instruction function on the arch, the
record only support MIPS. I only test record with QEMU and Linux
Kernel because the condition is limited.
Please give me your thought about the "record". Thanks a lot.

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

The following is how to use the record:
mips-gdb ../../../qemu/linux-2.6.18.2/vmlinux
(gdb) target remote localhost:1234
#You need run QEMU with the options "-S -s" before use this command.
(gdb) b main.c:499
Breakpoint 1 at 0x8010e64c: file init/main.c, line 499.
(gdb) c
Continuing.
Breakpoint 1, start_kernel () at init/main.c:499
499             printk(KERN_NOTICE "Kernel command line: %s\n",
saved_command_line);
(gdb) record
record: record and reverse function is started.
#The abbreviation of this command is "rec".
(gdb) n
#It need wait a moment because record will spend some time.
500             parse_early_param();
(gdb) reverse
record: GDB is set to reverse debug mode.
#The abbreviation of this command is "rev".
(gdb) b vprintk
Breakpoint 2 at 0x800307b8: file kernel/printk.c, line 515.
(gdb) c
Continuing.
Breakpoint 2, vprintk (fmt=0x0, args=0x0) at kernel/printk.c:515
515             if (unlikely(oops_in_progress) && printk_cpu ==
smp_processor_id())
(gdb) reverse
record: GDB is set to normal debug mode.
#But the running message is still gotten from the record message.
(gdb) n
507     {
(gdb)
515             if (unlikely(oops_in_progress) && printk_cpu ==
smp_processor_id())
(gdb)
521             local_irq_save(flags);
(gdb)
527             printed_len = vscnprintf(printk_buf,
sizeof(printk_buf), fmt, args);
(gdb)
524             printk_cpu = smp_processor_id();
(gdb)
527             printed_len = vscnprintf(printk_buf,
sizeof(printk_buf), fmt, args);
(gdb) p printk_cpu
$1 = 4294967295
(gdb) n
524             printk_cpu = smp_processor_id();
(gdb) p printk_cpu
$2 = 4294967295
(gdb) n
527             printed_len = vscnprintf(printk_buf,
sizeof(printk_buf), fmt, args);
(gdb) p printk_cpu
$3 = 0
(gdb) p printed_len
$4 = 0
(gdb) n
warning: GDB can't find the start of the function at 0xffffffff.

    GDB is unable to find the start of the function at 0xffffffff
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0xffffffff for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
533             for (p = printk_buf; *p; p++) {
(gdb) p printed_len
$5 = 0
(gdb) n
534                     if (log_level_unknown) {
(gdb) p printed_len
$6 = 87
(gdb) rev
record: GDB is set to reverse debug mode.
(gdb) n
0xffffffff80030878      533             for (p = printk_buf; *p; p++) {
(gdb)
warning: GDB can't find the start of the function at 0xffffffff.
0xffffffff80030868      527             printed_len =
vscnprintf(printk_buf, sizeof(printk_buf), fmt, args);
(gdb) p printed_len
$7 = 0
(gdb) p printk_cpu
$8 = 0
(gdb) n
524             printk_cpu = smp_processor_id();
(gdb)
0xffffffff8003085c      527             printed_len =
vscnprintf(printk_buf, sizeof(printk_buf), fmt, args);
(gdb) p printk_cpu
$9 = 4294967295

You can find out the change of the values of printk_cpu and
printed_len when the GDB normal debug and reverse debug.

Thanks,
teawater


Signed-Off-By: Teawater Zhu <teawater@gmail.com>