Re: GDB record target 0.1.0 for MIPS GDB-6.6 release (It make GDB support

Re: GDB record target 0.1.0 for MIPS GDB-6.6 release (It make GDB support

[Robert Bu]

> ------------------------------------------------------------------------
>
> GDB record target 0.1.0 for MIPS GDB-6.6 release (It make GDB support
> Reversible Debugging)
......
>
> 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.

Does the record target need any support at target side? Can I use other
simulator to utilize the reverse debugging feature?

> (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>
>
>

Thanks.

Robert.
20071018

Re: GDB record target 0.1.0 for MIPS GDB-6.6 release (It make GDB support

[Tea]

You can use any MIPS simulator with record target 0.1.0.

thanks,
teawater

On 10/18/07, Robert Bu <robert.bu@gmail.com> wrote:
> > ------------------------------------------------------------------------
> >
> > GDB record target 0.1.0 for MIPS GDB-6.6 release (It make GDB support
> > Reversible Debugging)
> ......
> >
> > 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.
>
> Does the record target need any support at target side? Can I use other
> simulator to utilize the reverse debugging feature?
>
> > (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>
> >
> >
>
> Thanks.
>
> Robert.
> 20071018
>