The gdb command step is supposed to step over the next line in the program. When executing in reverse, the step command for a line that contains two executable statements requires two step commands to get to the previous line not one step command as expected. The following is a test program to demonstrate the behavior. It is based on the regression test gdb.reverese/solib-reverse.c. int main () { int b[2] = {5,8}; b[0] = 1; b[1] = 2; b[0] = 6; b[1] = 9; /* generic statement, end part two */ b[1] = 10; b[0] = 20; return 0; } /* end of main */ Compile the program with -g and run on gdb Start by enabling recording and stepping forward. (gdb) break main Breakpoint 1 at 0x838: file solib-reverse-bug.c, line 2. (gdb) run Starting program: /home/carll/solib-reverse-bug Breakpoint 1, main () at solib-reverse-bug.c:2 2 { (gdb) list 1 int main () 2 { 3 int b[2] = {5,8}; 4 5 b[0] = 1; 6 b[1] = 2; 7 8 b[0] = 6; b[1] = 9; /* generic statement, end part two */ 9 10 b[1] = 10; (gdb) 11 b[0] = 20; 12 13 return 0; 14 } (gdb) record (gdb) step 3 int b[2] = {5,8}; (gdb) step 5 b[0] = 1; (gdb) step 6 b[1] = 2; (gdb) step 8 b[0] = 6; b[1] = 9; /* generic statement, end part two */ (gdb) step 10 b[1] = 10; (gdb) step 11 b[0] = 20; (gdb) step 13 return 0; As expected step advances to the next line each time, specifically line 8. Set the execution direction to reverse and step (gdb) set exec-dir reverse (gdb) step 11 b[0] = 20; (gdb) step 10 b[1] = 10; (gdb) step 8 b[0] = 6; b[1] = 9; /* generic statement, end part two */ (gdb) step 8 b[0] = 6; b[1] = 9; /* generic statement, end part two */ (gdb) step 6 b[1] = 2; (gdb) step 5 b[0] = 1; (gdb) step 3 int b[2] = {5,8}; (gdb) step You will note, that line 8 required two steps to get to the previous line. Step over the other lines worked as expected. This issue has been observed on Power PC and Intel. Note the above bug results in gdb.reverse/solib-presave.exp and gdb.reverse/solib-reverse.exp to fail. ./
Created attachment 14415 [details] reproduce.sh I've written a reproducer script reproducer.sh (generating test.c and gdb.in) based on comment #0. I first tried with gcc 7.5.0, but that one does not emit column info by default, so I added -gcolumn-info: ... $ gcc -g test.c ; readelf -wl a.out | grep -i column $ $ gcc -g test.c -gcolumn-info ; readelf -wl a.out | grep -i column [0x0000010f] Set column to 1 [0x0000011d] Set column to 7 [0x00000120] Set column to 8 [0x00000125] Set column to 20 [0x00000128] Set column to 8 [0x0000012c] Set column to 10 [0x0000012f] Set column to 1 ... Then, I used "b *main" to start at line 2 (otherwise, on x86_64-linux, it starts at line 3). Still, it doesn't reproduce for me with current trunk and x86_64-linux: ... $ ./reproduce.sh ... +b *main Breakpoint 1 at 0x400497: file test.c, line 2. +run Breakpoint 1, main () at test.c:2 2 { +record +target record-full +step 3 int b[2] = {5,8}; +step 5 b[0] = 1; +step 6 b[1] = 2; +step 8 b[0] = 6; b[1] = 9; /* generic statement, end part two */ +step 10 b[1] = 10; +step 11 b[0] = 20; +step 13 return 0; +set exec-dir reverse +step 11 b[0] = 20; +step 10 b[1] = 10; +step 8 b[0] = 6; b[1] = 9; /* generic statement, end part two */ +step 6 b[1] = 2; +step 5 b[0] = 1; +step 3 int b[2] = {5,8}; +step No more reverse-execution history. main () at test.c:2 2 { ... in other words, after 7 steps forward and 7 steps back I end up at the same point where I started: line 2. That's both with gcc 7.5.0 and gcc 12.2.1.
(In reply to Tom de Vries from comment #1) > That's both with gcc 7.5.0 and gcc 12.2.1. And I've tried both compiler also with gdb-12-branch, and all looks good there as well. So, I can't reproduce this on x86_64-linux.
As explained by Pedro Alves in this email thread (https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html), it is possible to reproduce this bug in x86_64, with a modified reproducer. Consider the following code: void func1 () { } void func 2 () { } int main () { int v = 0; func 1 (); func 2 (); return v; } and the debug session: (gdb) start Temporary breakpoint 1 at 0x40111c: file t.c, line 10. Starting program: /home/blarsen/Documents/downstream_build/gdb/reverse [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at t.c:10 10 int v = 0; (gdb) record (gdb) n 11 func1 (); func2 (); (gdb) 12 return v; (gdb) rn 11 func1 (); func2 (); (gdb) 11 func1 (); func2 (); (gdb) rn No more reverse-execution history. main () at t.c:10 10 int v = 0; (gdb) Without a line before the `func1 (); func2 ()` GDB mistakenly reports that we've reached the end of the recorded history, but that is an unrelated bug. Compiling the example program with no column information, we get instead the following session: (gdb) start Temporary breakpoint 1 at 0x40111c: file t.c, line 10. Starting program: /home/blarsen/Documents/downstream_build/gdb/reverse [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at t.c:10 10 int v = 0; (gdb) record (gdb) n 11 func1 (); func2 (); (gdb) 12 return v; (gdb) rn 11 func1 (); func2 (); (gdb) No more reverse-execution history. main () at t.c:10 10 int v = 0; (gdb)
Marking this as resolved as it is not failing any more.