Community
Participate
Working Groups
Currently when using the "Connect" button, the user is only allowed to select a single process. It would be nice to allow for a multi-selection. We would then need to attach to all the selected processes. I suggest that a failure in one attach would not prevent attaching to other processes.
Created attachment 179088 [details] Multiple process debug - selection Here are the steps for multiple selection , what do you think? 1 ) User selects a process 2 ) Than press add buttun 3 ) File dialog opens 4 ) User select executable which belongs to process. 6 ) User repeats steps 1 to 4 7 ) To finish the wizard user press "OK" button , and selected processes started to be debugged.
That is pretty cool! I'm not sure how often users will want to connect to more than one process at a time, so it may be a little over-kill to have to 'add' a process instead of simply double-clicking. Did you find the existing process launcher to be too limited? This brings up an interesting point. Since we have to open a file browser when launching a new process (or even for attach when to a remote target), how will this work when selecting multiple processes to add a once? This makes me wonder if a a multi-selection is a good idea at all...
I've had a request for this feature. The use case is that the user has multiple processes running the same binary and they want to be able to attach to all of them in a single operation.
So, we want to be able to select multiple processes and attach to all of them in a single operation. We have two cases to consider: local attach and remote attach. For a local attach, we should be able to simply tell GDB to attach to once process after the other, based on a multi-selection in the attach prompt. That should be easy. When dealing with a remote attach, DSF-GDB prompts the user for the location of the binary so we can tell GDB. This complicates the idea of doing a multi-select in the attach prompt. Say the user selects 5 processes. We will need to prompt for 5 binaries to be able to debug those 5 processes. That is pretty much as annoying as attaching to one process at a time, I would think. We can improve on this by assuming that if multiple processes are named the same, they have the same binary. I'll prototype something to see how it feels.
Created attachment 196593 [details] Prototype
(In reply to comment #5) > Created attachment 196593 [details] > Prototype This first prototype does the following: 1- Allows the user to select multiple entries in the attach dialog. The attach dialog was a TwoPaneElementSelector, but that type of dialog does not allow to actually select more than one entry; it allows muti-select, but when pressing ok, only one entry of the bottom pane is returned. So, I changed the attach dialog to be a simpler ElementListSelectionDialog, which is a single list of processes that allows multi-selection. We were not making use of the two panes anyway, so I think it is even better like this, is is more user friendly. 2- The process prompter, which uses the attach dialog, now returns an array of processes instead of the pid of just one process. 3- The GdbConnectCommand performs multiple attaches, one for each chosen process. In this prototype, if one attach fails, we ignore it and move on to the next attach. Also, if we don't support attaching to more than one process (no multi-process), we only attach to the first process and stop without any error. Finally, for a remote attach, we will prompt for each process binary separately; for the user to know which process is being requested, the title of the dialog shows the name of the process in question. The next thing I'd like to do is somehow check if two processes have the same name, and only prompt for the binary once for those processes.
Created attachment 196602 [details] Better prototype This prototype adds a map that remembers the path to the binary of a process with a particular name. So, if the user tries to attach to processes with the same name, we will only prompt once.
I like the feel of this feature. I'm not sure about the part of silently ignoring failed attach requests though. Also, I'll have to email the list about changing the attach dialog from a two-pane to a one-pane. I'll aim for Juno.
Created attachment 196699 [details] Prototype with double pane dialog After thinking about it, there is value in having a two-pane attach dialog. Having the second pane makes it easier to see what has been selected, especially if the selected processes are not next to each other in the top pane. Also, the bottom pane can give more info, although we don't use that. I found a way to keep the double pane dialog and get the result I wanted. This prototype disables the selection in the bottom pane, so as to make it clear to the user that whatever is shown in the bottom pane is what will be used for multi-attach. Also, pressing OK will return all selections instead of just the first one.
Created attachment 198776 [details] Git patch that allows multi-select This is the git patch that takes the two-pane process prompt dialog and allows multi-selection, which triggers a multi-attach. I have committed it to master.
Pawel, can you review?
Created attachment 198933 [details] Change title of dialog to reflect multi-select It was pointed out to me that the attach dialog said: "Select Process" "Select a Process to attach debugger to:" which don't reflect that we can do a multi-attach. I changed the strings to say: "Select Processes" "Select one or more processes to attach to:" Committed to master.
