Community
Participate
Working Groups
Bug 241423 introduced the capability of attaching a running GDB debugger to a new process, since GDB 6.8+ started to support this functionality. However, attaching to a new process from an existing launch creates some workflow problems: 1) A debug session is meant to be initiated through the launch process. 2) The launch configuration can contain information important to the process being debugged, such as source lookup mappings. 3) The attach action brings up a dialog to select a process from. It would be more natural for the user to browse through a view dedicated to showing running processes and initiate the attach action from there.
(In reply to comment #0) > 1) A debug session is meant to be initiated through the launch process. For now, the way I imagine multi-process debugging, is that a debug session is launched, connecting to a backend. The launch is then complete. During the debug session, the user can connect/disconnect at will to different processes. > 2) The launch configuration can contain information important to the process > being debugged, such as source lookup mappings. You are right about that. The solution at this time is that the user would specify in the launch a path containing the locations that should be searched to find different source code. solib-search-path is used in our OS because code is loaded as libraries. I'm not sure if there are other information needed from the launch, that is necessary for the processes being debugged. > 3) The attach action brings up a dialog to select a process from. It would be > more natural for the user to browse through a view dedicated to showing running > processes and initiate the attach action from there. The easiest solution was to popup the dialog, since CDT had already done the work :-) Another idea I was playing with was to use the debug view. We could have the debugged processes at the top of the view, maybe in a special container; under that, we could have all other processes, maybe in a different colored font. The user could then select a process and choose to connect to it; the process would then be moved to the debugged list of processes, and its threads and frames would appear. This is a little delicate and may be over-extending the debug view. Ultimately, as you point out, a Process View is probably the cleanest solution. The disadvantage is that this view would take more screen space, while re-using the debug view would share the space.
