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.
The Register unit tests made calls to createExecutionContext outside the
executor. This change fixes this and also one register test that didn't do what
it was meant to do.
When setting ATTR_WORKING_DIRECTORY in the launch (which was ignored before Bug 236058), we must now use an absolute path. The ATTR_WORKING_DIRECTORY was not actually used for the Breakpoint tests, so I removed it.
