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