Community
Participate
Working Groups
When doing a remote attach, it is possible to connect to a gdbserver that is already debugging a program. In that case, since the connection wasn't done explicitly by the user, there is no prompt for the binary on the host, and that binary is never specified to GDB. This is not a state that is good for GDB and errors can be seen, while code cannot be inspected. The problem can be seen when using disconnected-tracing as below. This can also happen with disconnected-printf. start gdbserver in one shell: > gdbserver --multi :9999 In another shell, cause that gdbserver to be connected to a program: > gdb loopfirst GNU gdb (GDB) 7.6.1 Reading symbols from /home/lmckhou/loopfirst...done. (gdb) target extended-remote :9999 Remote debugging using :9999 (gdb) attach 2588 Attaching to program: /home/lmckhou/testing/loopfirst, process 2588 (gdb) trace 7 Tracepoint 1 at 0x40055c: file loopfirst.cc, line 7. (gdb) tstart (gdb) set disconnected-tracing 1 (gdb) quit A debugging session is active. Inferior 1 [process 2588] will be detached. Quit anyway? (y or n) y Trace is running and will continue after detach; detach anyway? (y or n) y Detaching from program: /home/lmckhou/testing/loopfirst, process 2588 In eclipse, do a remote-attach connection to that gdbserver. You should see the program being debugged immediately show in the debug view, but the stack frames will not be sowing code properly. The following errors can be seen in the gdb console: warning: Could not load vsyscall page because no executable was specified try using the "file" command first. Trace is already running on the target. No symbol table is loaded. Use the "file" command.
This is a regression that occurred when we started to support multi-process. Before multi-process, we would specify the binary before connecting to the target, based on the launch configuration. With multi-process, since the user can debug multiple binaries, we couldn't necessarily only rely on the launch configuration, we added a dialogue to asks the user for the location of the binary. The simplest solution is to blindly set the binary before connecting, as specified in the launch config, in case we happen to connect to a target that is running that binary. If the target is not already debugging that binary, the dialogue will still be used when the user tries to attach, and will (possibly) overwrite the binary selection with the proper one. The limitations with this simple solution are: 1- the user must specify the proper binary in the launch config, instead of being prompted for it in the case the launch config binary is not the right one. 2- if gdbserver is debugging multiple different binaries when we connect, there is no way for the user to specify multiple binaries in the launch config. Another possible solution is to use the dialogue and ask the user for the binary or binaries, after we make the connection to a gdbserver that is already debugging one or more programs. The issue here is that it seems gdb does not like it when we specify the binary _after_ it is attached to the program. We would have to detach from the process, set the binary, and then re-attach. I'll play around with these solution and see what works well.
An even simpler way to reproduce this issue is to start gdbserver with a binary specified: > gdbserver --multi :9999 loopfirst In that case, using a C/C++ remote attach session, gdb will connects to the gdbserver using the extended-remote protocol, and gdbserver will indicate that it is already debugging a process, but we won't have specified the binary to gdb.
This has become less of a problem for us at the moment. Putting back in the queue.
