如何进入广东省数据库的前一行？

在 gdb 中是否可能转到当前执行行之前的一行。 例如:


void my_fun( somePtrType** arr,int start,int end)
{
// arr is an array of pointers to somePtrType
//line a
... some assignments
swap(&arr[ind1] , &arr[ind2] ) ;
//line b (current line )
}

我现在在第 b 行，可以检查那里的 arr值，但是我想回到第 a 行，检查当时 arr的内容。

我认为这可能是不可能的，因为调试器可以慢动作运行代码，但不能让它向后执行。
还有什么想法吗。

96568 次浏览
小开

According to the GDB docs, and "if the target environment supports it", yes.

小开

If your program is short, the usual trick is,

  1. Place a new breakpoint at the previous line
    • fire r to restart the debug

GDB was made to do that!

小开

Everyone wishes for a Omniscient Debugger like this one: https://web.archive.org/web/20150915150119/http://www.lambdacs.com/debugger/, but they are (depending on the language/machine) difficult to make and have a lot of bookkeeping to do.

At the moment on real hardware and not in a VM, it is close to impossible to do it.

小开

Short answer: No.

For workaround read below.

Though at line b it is not possible to determine the value at line a, it is possible to log the value of arr at a and b and other locations by only one breakpoint being hit.

  • Use the "display" command (display variable_name where variable_name is to be replaced with arr, *arr, **arr depending on what you are looking for) so that when any breakpoint is hit, the contents of the variable_name will be dumped on to the screen. Note that you can add to the display list when the variabe_name is in scope so that may require you to wait for your first breakpoint.
  • Create breakpoints at various locations of code where you are interested to log the value of variable_name. One such breakpoint would be at line a.
  • For each breakpoint, use command (command breakpoint_number) and instruct your breakpoint to not halt the execution of the program. The command that you need to use is continue followed by end. See example below.

(gdb) command 1

Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end".

continue

end

  • Put a breakpoint on line b.

Now when all other logging breakpoints are hit, the value of arr will be dumped on the screen but the breakpoint won't wait for user interaction and will auto-continue. When you hit a breakpoint at line b, you can see the past values of arr which would be logged in gdb itself.

Depending on the situation you can also dump (and display) a lot of useful information. For example you may also want to dump a loop counter (say i) if the above function is called 10000 times in a loop. That really depends on what you are trying to achieve.

小开
最佳答案

Yes! With the new version 7.0 gdb, you can do exactly that!

The command would be "reverse-step", or "reverse-next".

You can get gdb-7.0 from ftp.gnu.org:/pub/gnu/gdb

If you run into the error: Target child does not support this command. then try adding target record at the beginning of execution, after starting run.

Edit: Since GDB 7.6 target record is deprecated, use target record-full instead.

小开

Yes, it is possible, and straightforward, now, with real hardware (ie. not just with a VM). GDB-7.0 supports reverse debugging with commands like reverse-step and reverse-continue, on native linux x86 machines.

There is a tutorial here: http://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial

小开

If your setup code for arr is just above "line a" (a very commonly scenario), you can do it like this:

tbreak myfilename.c:123 (line 123 is the start of setup code for arr) then

jump 123

The "tbreak" prevents gdb from continuing (resuming) the program after the jump.

then you can step through the setup code or just set a breakpoint at "line a" and continue

小开

Not gdb but you can go back in history easily using a debugger called qira. You can use the up and down arrows to go back and forth, it also highlights which registers have changed.

enter image description here

小开

mozilla rr

https://github.com/mozilla/rr

GDB's built-in record and replay has severe limitations, e.g. no support for AVX instructions: gdb reverse debugging fails with "Process record does not support instruction 0xf0d at address"

Upsides of rr:

  • much more reliable currently. I have tested it relatively long runs of several complex software.
  • also offers a GDB interface with gdbserver protocol, making it a great replacement
  • small performance drop for most programs, I haven't noticed it myself without doing measurements
  • the generated traces are small on disk because only very few non-deterministic events are recorded, I've never had to worry about their size so far

The following example showcases some of its features, notably the reverse-next, reverse-step and reverse-continue commands.

Install on Ubuntu 18.04:

sudo apt-get install rr linux-tools-common linux-tools-generic linux-cloud-tools-generic
sudo cpupower frequency-set -g performance
# Overcome "rr needs /proc/sys/kernel/perf_event_paranoid <= 1, but it is 3."
echo 'kernel.perf_event_paranoid=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Test program:

reverse.c

#include <stdio.h>
#include <stdlib.h>
#include <time.h>


int f() {
int i;
i = 0;
i = 1;
i = 2;
return i;
}


int main(void) {
int i;


i = 0;
i = 1;
i = 2;


/* Local call. */
f();


printf("i = %d\n", i);


/* Is randomness completely removed?
* Recently fixed: https://github.com/mozilla/rr/issues/2088 */
i = time(NULL);
printf("time(NULL) = %d\n", i);


return EXIT_SUCCESS;
}

compile and run:

gcc -O0 -ggdb3 -o reverse.out -std=c89 -Wextra reverse.c
rr record ./reverse.out
rr replay

Now you are left inside a GDB session, and you can properly reverse debug:

(rr) break main
Breakpoint 1 at 0x55da250e96b0: file a.c, line 16.
(rr) continue
Continuing.


Breakpoint 1, main () at a.c:16
16          i = 0;
(rr) next
17          i = 1;
(rr) print i
$1 = 0
(rr) next
18          i = 2;
(rr) print i
$2 = 1
(rr) reverse-next
17          i = 1;
(rr) print i
$3 = 0
(rr) next
18          i = 2;
(rr) print i
$4 = 1
(rr) next
21          f();
(rr) step
f () at a.c:7
7           i = 0;
(rr) reverse-step
main () at a.c:21
21          f();
(rr) next
23          printf("i = %d\n", i);
(rr) next
i = 2
27          i = time(NULL);
(rr) reverse-next
23          printf("i = %d\n", i);
(rr) next
i = 2
27          i = time(NULL);
(rr) next
28          printf("time(NULL) = %d\n", i);
(rr) print i
$5 = 1509245372
(rr) reverse-next
27          i = time(NULL);
(rr) next
28          printf("time(NULL) = %d\n", i);
(rr) print i
$6 = 1509245372
(rr) reverse-continue
Continuing.


Breakpoint 1, main () at a.c:16
16          i = 0;

rr achieves this by first running the program in a way that records what happened on every single non-deterministic event such as a thread switch.

Then during the second replay run, it uses that trace file, which is surprisingly small, to reconstruct exactly what happened on the original non-deterministic run but in a deterministic way, either forwards or backwards.

rr was originally developed by Mozilla to help them reproduce timing bugs that showed up on their nightly testing the following day. But the reverse debugging aspect is also fundamental for when you have a bug that only happens hours inside execution, since you often want to step back to examine what previous state led to the later failure.

The most serious limitations of rr in my opinion are:

UndoDB is a commercial alternative to rr: https://undo.io Both are trace / replay based, but I'm not sure how they compare in terms of features and performance.


提交答案