Reverse execution doesn't work in gud-gdb

[jdm]

http://www.gnu.org/software/emacs/manual/html_node/emacs/Debugger-Operation.html#Debugger-Operation

This is different from regular M-x gdb mode in that it doesn't use the machine interface to gdb. It works quite well for rr replay -s 9999, except that any attempt to perform reverse execution on my traces yields:

(gdb) rn
Warning:
Cannot insert breakpoint -17.
Cannot access memory at address 0x2aaaab10bb30
Cannot insert breakpoint -21.
Cannot access memory at address 0x2aaaab6acd60

dl_main (phdr=<optimized out>, phdr@entry=0x400040, phnum=<optimized out>, phnum@entry=9, 
    user_entry=user_entry@entry=0x7fffffffde88, auxv=<optimized out>) at rtld.c:1592
1592    in rtld.c

whereas it works perfectly on the same recording when executed in gdb via rr replay:

Breakpoint 1, on_recv_data (conn=0x6182d0) at mongoose.c:4828
4828        printf("Error reported while handling request.\n");
(gdb) rn
4827      if (error_flag) {

[rocallahan]

Are you sure you're doing the set target-async 0 before target remote :9999?

[jdm]

Yes.

[jdm]

I tried upgrading from the stock gdb 7.7.1 to gdb 7.9 and now get this error when trying to start execution:

target.c:605: internal-error: default_execution_direction: to_execution_direction must be implemented for reverse async

[joneschrisg]

This first popped up in #1398, but roc resolved it in the followup #1430. So something in that fix must not be kicking on.

[jdm]

Interestingly I see the same behaviour when running gdb, sourcing the required macros, and using the remote target.

[rocallahan]

This is very confusing! rr doesn't do anything magical to gdb. You can see how we launch gdb in GdbConnection::launch_gdb. You might want to check that rr is execing the same gdb binary that you run from the shell.

[jdm]

Interestingly enough, when I use the exact commands that rr uses then gdb from the terminal works fine. The same commands for invoking gdb as part of gud-gdb do not. The only difference I observe in the output is this:
gud-gdb:

Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00002aaaaaaafa86 in ?? () from /lib64/ld-linux-x86-64.so.2

gdb:

Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00002aaaaaaafa86 in _dl_start (arg=0x7fffffffdf70) at rtld.c:380
380 rtld.c: No such file or directory.
(gdb)

[jdm]

Aha! You were exactly right; I still am not sure why the 7.7.1 gdb is being picked up by one and 7.9.1 by the other, but forcing gud-gdb to use 7.7.1 makes reverse execution work as expected.

[rocallahan]

That still leaves us with a bug to fix with 7.9.1, I guess? If you run that from the command line do you reproduce a bug? What if you force rr to use it?

[mijoharas]

On a similar point, do we have any idea how to use rr with the normal gdb command (to enable users to use gdb-many-windows-mode). In that mode gdb is usually started with the flag -i=mi or --interpreter=mi for a machine readable rather than human readable fromat which is used by emacs to display many different windows of information. On attempting to start rr from emacs gdb followed by rr replay like this we get:

(rr) Undefined command: "1-inferior-tty-set".  Try "help".
(rr) Undefined command: "2-gdb-set".  Try "help".
(rr) Undefined command: "3-gdb-set".  Try "help".
(rr) Undefined command: "4-enable-pretty-printing".  Try "help".
(rr) Undefined command: "5-file-list-exec-source-files".  Try "help".
(rr) Undefined command: "6-file-list-exec-source-file".  Try "help".
(rr) Undefined command: "7-gdb-show".  Try "help".
(rr) Undefined command: "8-stack-info-frame".  Try "help".
(rr) Undefined command: "9-thread-info".  Try "help".
(rr) Undefined command: "10-break-list".  Try "help".
(rr) Undefined command: "11-thread-info".  Try "help".
(rr) Undefined command: "12-break-list".  Try "help".
(rr) 

followed by this error message after every attempt to run a command:

(rr) continue
Undefined command: "-interpreter-exec".  Try "help".

If, however you try and do something like rr replay -i=mi it (obviously and correctly) points out that that is not a valid option for rr.

Does rr support the machine-readable gdb mode?

[rocallahan]

You can wrap gdb in a script that passes extra parameters to gdb (as well as forwarding any parameters passed to the script), and run rr replay -d <script> to launch your script.

[mijoharas]

Awesome, thank you. For anyone else that wants to get it working, it requires a small patch to gdb.el (for me) to make it work. for details see here.

[GitMensch]

I suggest closing this as ... "closed" (external issue).