Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-dd-dev] about ICommandControlDMContext

Hi Ling,
I had the same question when Pawel introduced the ICommandControlService interface.
>From bug 243611 comment #4 (
you can read:
> > Unlike other services, the ICommandControlService, can only deal with a single
> > context.  This means that we'll need multiple instances of that service, one
> > per commandControl.
> Yes this was indeed my intention.  If there are going to be multiple back ends
> active, they will be distinguished using their IDs.  The logic to do this could
> be somewhat ugly, but it could be hidden using a command control proxy that we
> talked about before.
I believe this ID is geared at supporting multiple backends within the same debug session.  Say if you debug multiple processors at once, for example.  This effort is tracked by Bug 225638.


From: dsdp-dd-dev-bounces@xxxxxxxxxxx on behalf of Ling.5.Wang@xxxxxxxxx
Sent: Mon 9/22/2008 7:07 PM
To: dsdp-dd-dev@xxxxxxxxxxx
Subject: [dsdp-dd-dev] about ICommandControlDMContext

As to this DMContext:
    public interface ICommandControlDMContext extends IDMContext {
         * Returns the ID of the command control that this context
         * represents.
        public String getCommandControlId();

I'm wondering what's the purpose of having CommandControlID in it.  To my knowledge, there can be several CommandControl service instances in several sessions, but there will be only one CommandControl service (or GDBControl service) instance in one session, thus there is no need to have an extra ID in addition to the session ID in the above context.  Actually I did a search and found no reference to the above "getCommandControlID()" method in DSF code.
Or in other words, my question is, do you see/foresee a use case that more than one CommandControl instances (e.g. more than one GDB processes) exist in one debug session ?
- Ling

Back to the top