Community
Participate
Working Groups
Currently, the debug view shows the single process we are debugging. With multi-process debugging, multiple processes should be shown in the debug view; the list processes shown is dynamic as the user attaches/detaches from processes. The RunControl service should be used to request the list of processes from GDB.
(In reply to comment #0) > ... The RunControl service should be used to request the list of > processes from GDB. For modularity and extendability, I think it would be good to separate this functionality out of the run control service and into a dedicated service. Depending on the type of debugging (single-process, multi-process, multi-core, etc) different implementations of such a service could be needed. It would be better not to tangle this with the relatively consistent run control functionality. When we first started implementing DSF services for GDB, we had an INativeProcesses interface for this purpose. However, as GDB wasn't really ready to utilize it, this service just got in the way. It may be a good time to look back and see if we shouldn't resurrect it.
Created attachment 106142 [details] Partially functional fix This patch attempts to take the first steps as adding a process list to the debug view. This is new territory for me, so I wanted to post this early. Here is the general preliminary design (which is really a first attempt that I'm not even sure is my final opinion): The LaunchVMProvider adds an extra layer between Container and Thread, provided by ProcessVMNode. The Container level now represents a processor instead of a process. The GdbRunControl is enhanced to provide processorData. Since I don't have a GDB allowing multi-process debugging, the RunControl service always returns a single process as the list of processes (getExecutionContexts) (for now). I decided to show the processor as a node in the debug view. The reason was that GDB will provide a -exec-continue --thread-group=all option, which tells me we will be able to resume all the processes to which GDB will be attached. Having a processor entry in the debug view allows to do this in the UI. This would be the behavior for a single process session, as we do now; so, a new line would be seen. At this point, I am having problems with events, such as ContainerResumedEvent. I'm not sure, but it may be necessary to make a distinction between processResumed and processorResumed, which mean containerResumed cannot be used for both. So, right now, the delta logic of the ProcessVMNode and ContainerVMNode is most probably wrong. In fact, things don't expand and select properly with this patch. I have a couple of questions to be able to continue: 1- IRunControl is designed for single process debugging or ready for mutli-process debugging. it is the events that are giving me trouble. 2- can I re-use ContainerVMNode to represent a processor and use ProcessVMNode for processes, or should ContainerVMNode still be used (maybe renamed), and enhanced for multiple processes, while a new node would be used for processors. In the VM, things seem ok with this patch (container for processor, processesVMNode for processes), but it becomes iffy when dealing with Container events. There are a lot more things that are not clear to me, but I figured I should start somewhere :-)
(In reply to comment #1) > (In reply to comment #0) > > ... The RunControl service should be used to request the list of > > processes from GDB. > > For modularity and extendability, I think it would be good to separate this > functionality out of the run control service and into a dedicated service. > Depending on the type of debugging (single-process, multi-process, multi-core, > etc) different implementations of such a service could be needed. It would be > better not to tangle this with the relatively consistent run control > functionality. Sounds good. I'll look into that. I'll do all this work in GDB only, for now. > When we first started implementing DSF services for GDB, we had an > INativeProcesses interface for this purpose. However, as GDB wasn't really > ready to utilize it, this service just got in the way. It may be a good time > to look back and see if we shouldn't resurrect it. Where can I get a glimpse of this? I looked in the archive a bit, but I didn't find anything.
(In reply to comment #3) > > When we first started implementing DSF services for GDB, we had an > > INativeProcesses interface for this purpose. However, as GDB wasn't really > > ready to utilize it, this service just got in the way. It may be a good time > > to look back and see if we shouldn't resurrect it. > > Where can I get a glimpse of this? I looked in the archive a bit, but I didn't > find anything. Found it. Sorry.
(In reply to comment #2) > I decided to show the processor as a node in the debug view... Are you sure this is what you want to do as the default behavior? This is where I think the "one size fits all" approach to layout in debug view starts to get strained. It is true that this debugger functionality needs to be exposed, but for most users who just want to launch a single program they've written, it's a big distraction. The intention of DSF architecture is to make it easy to customize the layout in the views. I hope we can take advantage of that in the GDB debugger, and customize the layout with something similar to the services factory. > 1- IRunControl is designed for single process debugging ... Yes, I believe the interface itself is generic enough to represent arbitrary container/execution context configurations. So hopefully we can solve your event issues without needing anything new in this API. > 2- can I re-use ContainerVMNode to represent a processor... The IContainerDMContext can represent arbitrary hierarchy of containers, but the AbstractContainerVMNode is not quite ready to handle this. The proper solution to this problem is to extend the AbstractContainerVMNode to be recursive. This single VM node should be used to supply elements at all the levels (processors and processes, etc) and to generate the deltas for all those levels as well. There's an example of a recursive VM node in the examples plugin, which I think is better than the VariablesVMNode, because it deals with deltas. Also, you should see if the TCF debugger integration doesn't contain a similar solution for the container node (see http://wiki.eclipse.org/DSDP/TM/TCF_FAQ). I've been meaning to review the TCF implementation for a while now, but I never seem to have enough time. This is probably a good reason to... > There are a lot more things that are not clear to me, but I figured I should > start somewhere :-) The view model is pretty complicated logic, but I've been encouraged lately at how quickly Toni's been able to start contributing to it, so it' can't be that bad :-) (In reply to comment #3) > Where can I get a glimpse of this?... We lost a lot of CVS history when we renamed plugins, but if you look in /cvsroot/dsdp/org.eclipse.dd.dsf.archive, you should still be able to find it.
(In reply to comment #5) > (In reply to comment #2) > The intention of DSF architecture is to make it easy to customize the layout in > the views. I hope we can take advantage of that in the GDB debugger, and > customize the layout with something similar to the services factory. Would that mean selecting different VMNodes depending on some discriminator, like an option (multi-process) or a type (remote)? > > 1- IRunControl is designed for single process debugging ... > Yes, I believe the interface itself is generic enough to represent arbitrary > container/execution context configurations. So hopefully we can solve your > event issues without needing anything new in this API. Excellent. > > 2- can I re-use ContainerVMNode to represent a processor... > The IContainerDMContext can represent arbitrary hierarchy of containers, but > the AbstractContainerVMNode is not quite ready to handle this. [...] > There's an example of a recursive VM node in the examples > plugin, which I think is better than the VariablesVMNode, because it deals with > deltas. Also, you should see if the TCF debugger integration doesn't contain a > similar solution for the container node (see > http://wiki.eclipse.org/DSDP/TM/TCF_FAQ). I've been meaning to review the TCF > implementation for a while now, but I never seem to have enough time. This is > probably a good reason to... I'll see what I can learn. thanks for the pointers. > > There are a lot more things that are not clear to me, but I figured I should > > start somewhere :-) > The view model is pretty complicated logic, but I've been encouraged lately at > how quickly Toni's been able to start contributing to it, so it' can't be that > bad :-) I don't claim to be as smart as Toni :-) More to come...
Created attachment 107266 [details] Add multi-process support for single process GDB With the new IProcesses service we implemented in bug 239050 it became easier to have the Debug view support multli-process debugging. This new patch replaces the old approach, and attempts to add support for multli-process debugging still using the single-process GDB. The goal was to make our DSF/GDB implementation be ready for multi-process support, even without having GDB support it. We could have had this done from the very start (although no one had the time for it back then) The patch does the following: - adds a new IMIExecutionGroupDMContext to represent the new MI thread-group concept. This context is used in this patch as an IContainer for the process. - make ContainerVMNode use the IProcesses service instead of hard-coding the information - splits GDBProcesses into MIProcesses and GDBProcesses to proper package access - make MIStoppedEvent use IProcesses to create the IContainer context instead of having it hard-coded. - make all event using MIStoppedEvent match the changes - make MIRunControlEventProcessor and CLIEventProcessor use the IProcesses service to get the proper container. Preliminary testing shows that this patch works well with the current GDB (Basically, nothing changes in the debugging experience). The JUnit tests fail a lot because of an issue with CommancCache.isTargetAvailable(). When fixing this, only one tests fail. I did not fix the issue because it is being discussed in Bug 237325. I made the changes in such a way that I believe is backwards compatible. In fact, in the changes I made to the event classes I kept the old method (which we no longer use) because I thought removing it would break the API.
Created attachment 107272 [details] Add multi-process support for single process GDB 2 I had done a minor cleanup to the previous patch which broke things. This patch fixes things again. Another note about the new approach I took: basically, I inserted a new layer between GDBControlDMContext and IMIExecutionDMContext. However, unlike the original approach, I am not showing the GDBControlDMContext in the debug view, so really, the debuggins session should look exactly the same as it was before.
I started looking at this patch. It looks like it needs merging with the GDBProcesses class that's already head though, so I couldn't get it to compile. My first observation is about the MI stopped events. At the time I wrote it I didn't really like passing in the run control service to the parse() methods, and I think passing in the processes service makes it even uglier. Perhaps it would be better to parse the "thread-id" and "group-id" fields in the MIRunControlEventProcessor and just passing in the correct context to the event's parse() method. This way, if an MI-based debugger doesn't support group-ids or doesn't have and IProcesses implementation, it could still use these event objects. The second place I looked is the use of IMIExecutionGroupDMContext. I don't know what kind of discovery mechanism GDB is going to provide to determine whether a given group context represents a process with an address space, which groups can be used to set breakpoints on, etc. But, for now I think we can make the assumption that an execution group represents a process or a core, and they both have an address space and can be used to set breakpoints, send signals, etc. So either MIExecutionGroupDMC should implement the context interfaces that GDBControlDMContext implements, or more correctly there should be a GDBExecutionGroupDMC which does. In either case, GDBControlDMContext should not implement these interfaces anymore since this context now becomes just an empty parent context which could be later used to identify the correct command control to send the commands to. In fact the GDBControlDMContext class could be eliminated and MIControlDMContext could be used instead. All in all though the patch looks pretty clean to me.
Created attachment 107740 [details] Add multi-process support for single process GDB updated this is updated patch with HEAD. It does not incorporate comments yet. I am working on this now.
Created attachment 107774 [details] multi-process support for single process GDB after comments (In reply to comment #9) > My first observation is about the MI stopped events. At the time I wrote it I > didn't really like passing in the run control service to the parse() methods, > and I think passing in the processes service makes it even uglier. Perhaps it > would be better to parse the "thread-id" and "group-id" fields in the > MIRunControlEventProcessor and just passing in the correct context to the > event's parse() method. This way, if an MI-based debugger doesn't support > group-ids or doesn't have and IProcesses implementation, it could still use > these event objects. That is much cleaner! The new patch does this. > The second place I looked is the use of IMIExecutionGroupDMContext. [...] > In fact the GDBControlDMContext class > could be eliminated and MIControlDMContext could be used instead. I agree that GDBControlDMContext must be modified properly, except that it is too early for me to know for sure how GDB will behave. So, I will leave this issue open under Bug 241317. I am waiting for progress on the non-stop patch before committing this one, to avoid merging.
Created attachment 108153 [details] broken multi-process support for single process GDB after comments with non-stop Updated my patch with the non-stop changes. Some minor compilation things to fix, but I wanted to store this, just in case my disk crashed... you never know :-)
Created attachment 108237 [details] final multi-process support for single process GDB This patch is fully updated with the non-stop changes. Any method who's signature changed has been kept and deprecated. With this patch, our debug session will now be in a multi-process situation, with only one process being debugged. At this point, there should be no visible changes in the debugging experience. I will commit. Comments are always welcome and appreciated (although this one has been reviewed already)
Created attachment 108258 [details] MIRunControlEventProcessor change for API similarity This change to MIRunControlEventProcessor does the same thing as before, but it avoids me having to deprecate an old method and create a new one. Committed.
Created attachment 108259 [details] ContainerVMNode should not show process after execution is finished In my conversion of ContainerVMNode I forgot to add the check to make sure the inferior was still running. This check is now in GDBProcesses Committed.
This bug was meant to track the changes to the debug view to support multi-process. I am hopeful that the debug view is now ready for multi-process.
That's indeed rather ugly :-(. Another option may be to just pass the launch configuration in a single set...() call, then let GDBControl extract the parameters as needed. This may create some code duplication, but maybe not.
(In reply to comment #17) > That's indeed rather ugly :-(. Another option may be to just pass the launch > configuration in a single set...() call, then let GDBControl extract the > parameters as needed. This may create some code duplication, but maybe not. > I believe this comment was meant for bug 241985. I will put it there.
Reviewed.
DD 1.1 reelased!
