Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Obtaining IExecutionDMContext object in DSF

Thanks guys. All the info was very helpful.

Rohit

On Thu, Jul 22, 2010 at 3:16 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Rohit Girme
> Sent: Thursday, July 22, 2010 1:26 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Obtaining IExecutionDMContext object in DSF
>
> Hi ,
>
> Thanks Pawel.
> Based on all the replies and the documentation, I inferred
> the following
>
>
> *     IContainerDMContext roughly corresponds to a process or
> a thread group while IExecutionDMContext corresponds to a thread.

IContainerDMContext corresponds to a process (and a thread-group
which is a GDB-specific term used in GDB 7.0 or more to denote
a process).

IExecutionDMContext corresponds to _both_ processes and threads.
You can see that
IContainerDMContext extends IExecutionDMContext
So, if you have an IExecutionDMContext you don't yet know if
it is a thread or a process.  To know this, you can simply
check that the IExecutionDMContext you have is also
an instance of IContainerDMContext which will indicate
a process.

>
>             Using IContainerDMContext for any run control
> activity will cause the entire process and thus all threads
> in it to undergo that activity.

Note quite.  Passing an IContainerDMContext to a runControl
method means that you want to perform that method on a
process, but the service may not support that.
For example,  MIRunControl.step() will make sure that the
context it receives is repersenting a thread, and if not
it will abort the operation.  An even better example is
the MIRunControl.canStep() method which start with

if (context instanceof IContainerDMContext) {
 rm.setData(false);
 rm.done();
 return;
}

because DSF-GDB does not support stepping a process.

 > *    IContainerSuspendedDMEvent#getTriggeringContexts()
> returns an array of IExecutionDMContext. After going through
> the implementation of that method in MIRunControl, I believe
> the current thread context ( IExecutionDMContext ) will be
> the first element of that array. If not is there any way to
> find the current one ?? (Something similar to
> ICDITarget.getCurrentThread )

In DSF-GDB there will only be one triggering context.  So
you can use the first element.  It would be safer the make
sure the array does contain at least one element, which it should.

> *     I tried DebugUITools.getDebugContext() ( I could not
> find any getActiveContext() ). And as you said, it returns
> null since my command is in a service.
>
> Am I right about the above statements ?
>
> Thanks,
> Rohit
>
>
>
> On Thu, Jul 22, 2010 at 11:55 AM, Pawel Piech
> <pawel.piech@xxxxxxxxxxxxx> wrote:
>
>
>       On 07/22/2010 08:47 AM, Rohit Girme wrote:
>
>               Hi,
>
>               Thanks Marc, things are a bit clearer than before.
>               I tried the things you suggested.
>
>               I used IRunControl.ISuspendedDMEvent instead of
> MIStopped. Then I use event.getDMContext(). However this
> gives me an instance of IContainerDMContext instead of
> IExecutionDMContext. If I use MIStopped then in the Variables
> view, if I select the DMC variable I see
>
>
> gdb[0].proc[].threadGroup[]gdb[0].proc[].OSthread[1].thread[1].
>
>               But if I use ISuspendedDMEvent, I see
>
>               gdb[0].proc[].threadGroup[]
>
>
>       If the stopped event causes the entire process to
> suspend (as is always the case with GDB all-stop mode), then
> the event sent by the run control service will be a
> IContainerSuspendedDMEvent.  The main subject of container
> suspended event is the container, but since you're after the
> thread that caused the suspend, you can get it from
> IContainerSuspendedDMEvent.getTriggeringContexts().
>
>
>
>               In DsfResumeCommand, IExecutionDMContext is
> acquired from DsfCommandRunnable#getContext(). I dont have
> access to that method since I am using DsfRunnable with
> DsfExecutor.submit() method (similar to PDATerminate in PDA
> example code. This is because I do not have Object element
> and IDebugCommandRequest request objects required in
> DsfCommandRunnable's constructor).
>
>               Hence I am still stuck at the same point. Hope
> the info I gave you helps in answering my question.
>
>
>       The context from Debug view is relevant if your command
> is to be triggered by some user action.  You can obtain the
> active debug context using DebugUITools.getActiveContext().
> However, if your command is in a service and is reacting to
> another service event then the UI debug context will be of no
> use to you.
>
>       Hope this helps,
>       Pawel
>
>
>
>
>
>               On Thu, Jul 22, 2010 at 7:14 AM, Marc Khouzam
> <marc.khouzam@xxxxxxxxxxxx> wrote:
>
>
>                       Hi,
>
>                       DSF is a generic framework so, as Pawel
> said, it's hard to answer your question.
>                       However, if you are asking about
> DSF-GDB, which is a specific implementation of DSF, then it
> becomes easier.
>
>                       Since you talk about MIStopped events
> which are a DSF-GDB concept, I will assume you are asking
> about DSF-GDB.
>
>                       Using the RunControl service does
> require an IExecutionDMC.  Of course, you should use the DMC on which
>                       you want to perform the RunControl
> operation.  An IExecutionDMC represents either a thread or a
> process in DSF-GDB.
>                       An IContainerDMC represents a process
> only.  So, for example, if you want to resume(), you must
> specify the IExecutionDMC
>                       for the thread (or process, if you
> support resuming a process) that you want to resume.
>
>                       How to you find that IExectionDMC?  It
> entirely depends on what you are doing at the time.  Did GDB
> just stop and you
>                       want to get the ExecutionDMC that
> caused the stop?  That is when you would use the MIStopped
> event, although I recommend
>                       using ISuspendedEvent.  But if you are
> trying to do a resume(), normally, it is the currently
> selected element in the
>                       Debug View that holds the IDMContext
> you want.  You can look at how DsfResumeCommand gets the
> context as provided
>                       by the platform.
>
>                       I hope this helps.
>
>                       Marc
>
>                       ________________________________
>                       From: cdt-dev-bounces@xxxxxxxxxxx
> [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Rohit Girme
> [rgirme@xxxxxxx]
>                       Sent: July 21, 2010 10:00 PM
>                       To: CDT General developers list.
>                       Subject: Re: [cdt-dev] Obtaining
> IExecutionDMContext object in DSF
>
>
>                       Hi,
>
>                       Yes. The missing was variable was done
> intentionally. Eclipse would have errored out in that case.
>                       I intend to use IExecutionDMContext
> object with IRunControl methods like suspend, resume,
> canSuspend etc. Also IStack methods like getTopFrame etc.
> Generally speaking many methods in the DSF debug plugin
> require IExecutionDMContext.
>                       Hence my questions.
>
>                       Thanks,
>                       Rohit
>
>
>                       On Wed, Jul 21, 2010 at 5:39 PM, Pawel
> Piech
> <pawel.piech@xxxxxxxxxxxxx<mailto:pawel.piech@xxxxxxxxxxxxx>> wrote:
>                       The statement below would not compile
> because there seems a variable name missing from the second
> declaration.  But if I understand its intent correctly, it's
> equivalent to:
>
>                       IExecutionDMContext dmc =
> (event.getDMContext() instanceof IContainerDMContext) ?
> event.getDMContext() : null;
>
>                       Without understanding what you want to
> do with the context, i can't really answer your questions.
>
>                       Cheers,
>                       Pawel
>
>                       On 07/21/2010 02:30 PM, Rohit Girme wrote:
>                       Hi,
>
>                       I am trying to use/call DSF services
> for some time now. For many of these services related to "run
> control" we need an IExecutionContext object. The way I do it
> is as follows :
>
>                                IContainerDMContext  abc =
> DMContexts.getAncestorOfType(  event.getDMContext(),
> IContainerDMContext.class   )
>
>                                 if (abc != null)
>                                  {
>
>                                    IExecutionDMContext  =
> !event.getDMContext().equals( abc ) ? event.getDMContext() : null
>
>                                  }
>
>                       This piece of code is inside an event
> listener, which listenes for an MIStopped event. So
> basically, I get  " IExecutionDMContext " from MIStopped
> event object. I tried using ISuspendedDMEvent instead, to
> make it generic. However it does not give the same result. I
> found the above piece of code in some DSF file. So I know
> some DSF class uses it. I have been looking through the
> source code for a while now. But this is the only way I found
> that works.
>
>                       My questions are :
>
>                       Is the process I described above, the
> right one ?
>                       Is there any better way to get the
> IExecutionDMContext object ? Something more generic.
>
>
>                       --
>                       Thanks & Regards,
>                       Rohit Girme
>
>
>
>
>
>       _______________________________________________
>       cdt-dev mailing list
>       cdt-dev@xxxxxxxxxxx
>       https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>
>
>
> --
> Thanks & Regards,
> Rohit Girme
>
>
> _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



--
Thanks & Regards,
Rohit Girme


Back to the top