| Re: [cdt-dev] gdbserver "attach" doesn't fully init the session? |
|
Hi Martin,
My answer has ended up being pretty long, but the Remote story is not simple. I hope you can decipher my awkward explanation below. Let me start by saying that the remote debug handling would benefit from some simplification. GDB has evolved a lot in the last few years and many of the things CDT used to need to do are no longer necessary. A simple example is that GDB/gdbserver now allow to both attach to multiple processes, but also start multiple processes in the same session; this blurs the line between what CDT calls a "remote-attach" session vs the single process "remote" session. That being said, lets deal with what CDT does now :) > When I attach multiple processes through one gdbserver, is there any extra benefit compared to attaching multiple processes with one gdbserver each ? The main reason is that some targets only provide a single instance of the debug agent, so GDB has to access all processes through that single agent. But there are other advantages, such as: - re-using a GDB that is already properly setup - better caching for duplicated requests (we don't cache across debug sessions) - a better contained representation of the target for global concepts (e.g. OS Resources view) - allows for grouping and run-control on groups (this is coming to both CDT and GDB) - etc > For example, could I set a breakpoint in process A that would also stop process B ? As you know, when you set a bp in Eclipse, it will affect all sessions, so if you run one session with multiple processes, or multiple sessions with one process each, the Eclipse breakpoints will affect everything. On the other hand, if you were to set a breakpoint directly with GDB, then yes, it will affect all processes that under the control of that GDB only. > The reasons why we’re not going with the green button multi-attach right now include > - Bug 400033 : In a Cross setup, it’s very awkward having to browse to the local exe path when the remote path could be mapped automatically This would benefit from being improved, and you guys started working on that. But I think that starting gdbserver pointing to a process, or pointing to that same process from Eclipse, technically requires the same knowledge of the location of that process from the user. > - Gdbserver lifecycle: One gdbserver –multi on the remote seems not sufficient. At least to me on Luna SR2 it’s unclear how to “add another attach” to an existing attached process (the green attach button is disabled after the initial attach). On the other hand, if Eclipse starts the gdbserver when does it die ? The Automatic remote mode only supports single process debugging at this time. This is what I was referring to above as old GDB limitations. We could enable multi-process in that case with today's GDB. To 'attach' to a 'gdbserver --multi' we have a different launch, which is not very visible as part of the "C/C++ attach to application" launch config type. The FAQ tries to clarify this. Please have a look at the "Remote attach launch" part of this page: https://wiki.eclipse.org/CDT/User/FAQ#How_do_I_debug_a_remote_application.3F This remote mode does not start gdbserver so that it can be used to connect to targets that provide a debug agent as a daemon. However, with some cleanup, we could improve the Automatic Remote launch to start gdbserver with the --multi flag (I believe Mikhail has a patch for that a while ago). In that case, CDT would kill gdbserver when the user killed the entire launch, as compared to killing individual processes. Related to that, there is a preference that allows to keep a debug session alive, along with GDB, even when all debugged processes are gone (Preferences->C/C++->Debug->GDB->"Terminage GDB when last process exits"). The user can then stay connected to a target and attach/start new processes. > - Workflow: After running the “Attach Launch” it’s awkward having to click “Attach” again inside the debugger. Maybe the approach CDT takes now is not the best. The idea was that a user may want to inspect the target using GDB without actually attaching to a process (e.g., OS Resources view). We could choose to automatically pop-up the attach dialog, as we do in the local attach case. The user could even press Cancel on that dialog if that is not what they wanted. If you feel this would be a better user experience, please open an enhancement bug. > - Consistency: “Run” Launches are started outside the debugger, but “Attach” is done inside the debugger I'm not sure what you mean here. Probably related, CDT/GDB now allows to both attach to many processes, but also to start multiple new ones, all in the same session. Note the Debug's view menu action "Debug New Executable..." available when multi-process is supported (non-stop, remote-attach session). I hope this helps, and I'd like to continue the discussion to help us find the path toward a simplified Remote launch experience for CDT. Thanks Marc > > How are others solving this ? > Any comments / thoughts would be welcome. > > BTW, BIG BIG thanks to the whole CDT community for your responsiveness. I’m amazed time and again about your timely expert answers to my many questions J > > Thanks, > Martin |