This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]