The public GDB now supports non-stop for linux.
This patch fixes the version number we were using and allows the user to click the non-stop checkbox in the launch.
When non-stop mode is requested by the user, the FinalLaunchSequence now issues:
maint set linux-async 1
set breakpoint always-inserted 1
-gdb-set non-stop on
Ultimately, with the official GDB release, only the last command should be needed.
This patch adds more usage of the IProcesses service. I believe the patch is
backwards compatible with our 1.0 release (not with the latest HEAD). The
patch does the following:
1- cleanup context hierarchy to become:
MIControlDMContext
|
MIProcessDMC (IProcess)
MIExecutionGroupDMC __/ |
(IContainer) |
| MIThreadDMC (IThread)
MIExecutionDMC _____/
(IExecution)
Notice how I put MIControlDMContext at the top.
The create*DMC methods have been updated accordingly.
The constructors of the MI*DMC classes have been updated accordingly.
2- Deprecated GDBRunControl.getThreadData() and GDBRunControl.getProcessData()
and have GdbThreadFilterEditor and ThreadVMNode use IProcesses instead.
3- because of (2) I was able to remove IGDBRunControl and GDBRunControlNS
completely.
4- Made MIProcesses.getExecutionData() fetch the thread data using
CLIInfoThreads as is done (but deprecated) in GDBRunControl.getThreadData()
5- Added a cache and event listeners to MIProcesses to cache CLIInfoThreads.
6- Update MIRunControlEventProcessor and CLIEventProcessor to use
MIControlDMContext as their top context instead of IContainerDMContext
removes the abstract from the methods, and adds ICommandControl, ISignals and ISymbols. It also uses alphabetical order to make it easier to know if something is forgotten.
This change adds support for multli-process debugging although we are still using the single-process GDB.
With this fix, 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.
If no frame context is provided in an expression, but an execution (thread) is present, then we define the expression to belong to the top-most frame of that thread.
Makes getAncestorOfType() return the closest ancestor in terms of
depth. Also adds a new method, getAllAncestorsOfType(), which returns all
the ancestors of the specified type in an array.
Use the generic IDMContext instead of IContainerDMContext because some debuggers may not have a run control service
Replace IThreadDMData.getDebuggingContext() with method getDebuggingContext()
This patch cleans up MITargetAttach/Detach to use the context properly. Since these classes are new, we don't need to worry about an API change.
A new class IMIProcessDMContext is introduced to be able to access the pid.
This previous change was a mistake. I added the ability to build an expression with a process
as a parent, or any other ExecutionContext, but it does not make sense to have
an expression refer to a processor or a core. I may make sense to have an
expression refer to a process and not a thread, but currently, the Expression
Service does not handle this properly even at the thread level (vs frame
level).
Therefore, I'm removing this patch and will open a new bug about the Expression
Service.
some improvements to the IProcesses interface where needed:
1- getRunningProcesses() should take an IContainerDMContext as a parameter to prepare for multi-core/multi-processor debugging.
2- attachDebuggerToProcess() should return an IContainerDMContext as part of the requestMonitor. This is because, once a process is attached to, it will then need to have a container context to use the RunControl service.
3- getProcessesBeingDebugged() should take an IContainerDMContext as a parameter to prepare for multi-core/multi-processor debugging. Also, it should return an array of IContainerDMContexts as part of the requestMonitor; this is because, processes that are being debugged should have a container context to use the RunControl service.
