Community
Participate
Working Groups
With the multi-process support, it is now possible to debug running processes (attach) and new processes in the same session. This makes DSF-GDB notion of an 'attach' debug session misleading. Currently, we have checks based on if the session is 'attach' or not, and prevent starting a new process. Run a remote-attach session using gdbserver --multi (needs GDB 7.2.1 to work properly) and try to create a new process. The process will not start because StartOrRestartProcessSequence_7_0 checks that the session is 'attach' and assumes we cannot start a process. We somehow have to properly deal with the concept of an 'attach' session, while keeping things working for pre-multi-process.
Created attachment 194847 [details] First part of fix This patch cleans up the path to create a new process from an attach session. With this patch, a local attach session now allows to create a new process. As for the remote attach case, I ran into a deadlock. The reason is that for a remote attach, the connect action (GdbConnectCommand) needs to prompt the user for the path to the binary (not needed for local attach), which can deadlock because GdbReverseToggleCommand also locks the UI thread. I'm going to look at how to fix this. I'll commit this patch, as it at least fixes the local attach.
*** cdt cvs genie on behalf of mkhouzam *** Bug 340535: Attach session should allow to create a new process for multi-process [*] StartOrRestartProcessSequence_7_0.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/StartOrRestartProcessSequence_7_0.java?root=Tools_Project&r1=1.8&r2=1.9 [*] DebugNewProcessSequence.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/DebugNewProcessSequence.java?root=Tools_Project&r1=1.5&r2=1.6
It turns out that starting a new process on a remote target is more complicated than I thought. We would need to also tell GDB where the binary that needs to be run is located on the target, not just the host. This goes beyond the scope of this bug. I've opened Bug 344890 about this. So, the fix for this bug already allows to create a new process for a local attach session. We'll deal with the remote case separately, but not for this release.
(In reply to comment #1) > As for the remote attach case, I ran into a deadlock. The reason is that for a > remote attach, the connect action (GdbConnectCommand) needs to prompt the user > for the path to the binary (not needed for local attach), which can deadlock > because GdbReverseToggleCommand also locks the UI thread. I'm going to look at > how to fix this. I've opened Bug 344892 about the deadlock.
