Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-debug-dev] Changes/exploration to the CDI interface 
> So why to you need to group stackframes?  I thought you had a limit to
deal with deep level stacks or deep recursions? 

For the back ends that don't support threads. They don't want to add
dummy threads and see the "target -> thread -> stack frame" hierarchy in
the Debug view. 
In general, the idea is to use only "service" interfaces instead of the
"object" interfaces like ICDITarget, ICDIThread, etc in the adapters. I
am using the DSF terminology here, of course these are not real
services, but this is a step towards it. 
For example, instead of implementing the ICDITarget interface,
implementers need to implement a target object that only provides the
services relevant for this particular backend. In case of the "target ->
stack frame" model, the target would implement ICDIStack, not
ICDIThreadGroup. The content adapter would display the stack frames as
the target's children. It's a way to support flexible hierarchy in the
Debug view.
Of course, it would be better to use something like getService() to get
ICDIStack from the target object instead of using "instanceof", but as I
mentioned before it's just a first step.  
As an example, I can post the code of the content adapter I am using. I
don't have it here, it is on my home computer.
 
> Sounds good, but then the interface now carries Eclipse interfaces.
Nop, the implementation carries an Eclipse class.
org.eclipse.cdt.debug.mi.core.model.Target extends PlatformObject.

-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Alain Magloire
Sent: 26 September 2006 17:37
To: CDT Debug developers list
Subject: [cdt-debug-dev] Changes/exploration to the CDI interface

Bonjour,
  This is an excerpt from an email exchange with Mikhail that we think
would be more beneficial in the mailing list;


> The "workarounds" I mentioned are not hacks or real workarounds. 

> For example, there is ICDIThreadGroup interface that in fact groups 
> all thread related functionality (getThreads, getCurrentThread). I use

> it instead of ICDITarget in the content adapter to get threads.
>

Right, the ICDIThreadGroup was to group thread and allow "atomic"
actions on them.  For example, if you have a set of threads in a thread
group you could do next, step, etc ... on the set.  This was interesting
for debuggers or frameworks that supporting "lock steps".  Another
example is distributed systems where the session encapsulates multiple
debuggers, then we could create an new thread group with different
threads from different debuggers/target and make them step in lock.
Unfortunately not many debugger frameworks support this.
 
> Roughly, I replace (element instanceof ICDITarget) by (element 
> instanceof ICDIThreadGroup). In this case any object that implements 
> ICDIThreadGroup will have threads as children.
>

Good!!
ICDIThreadGroup and ICDITarget are different although a target in the
CDI model can be seen as a grouping of thread, but that is just a side
effect.


> The ICDIThreadGroup is in place, but for stack frames I need to group 
> the stack frame related functionality under ICDIStack interface.

Grouping of stackframe was not done because we thought it was overkill
and more simply there was no practical need for it.  The only nitpicking
is the name the interface; ICDIStackGroup or ICDIStackframeGroup to be
consistent.
So were can one get a stack frame group?

public interface ICDIThread extends ...., ICDIObject {

	/**
	 * @deprecated use getStackFrameGroups()
	 */
	ICDIStackFrame[] getStackFrames() throws CDIException;

	/**
	 * @deprecated use ICDIStackFrameGroup.getStackFrames(fromIndex,
len)
	 */
	ICDIStackFrame[] getStackFrames(int fromIndex, int len) throws
CDIException;


	/**
	 * New interface
	 */
	ICDIStackFrameGroup[] getStackFrameGroups() throws CDIException;
	
}

public interface ICDIStackFrameGroup extends ICDIExecuteStepReturn,
ICDIObject {

	ICDIStackFrame[] getStackFrames() throws CDIException;

	ICDIStackFrame[] getStackFrames(int fromIndex, len) throws
CDIException; }


So why to you need to group stackframes?  I thought you had a limit to
deal with deep level stacks or deep recursions?

> Same
> is for terminate and disconnect related functionality. This is an 
> extension of CDI, but it is not going to affect any implementation at
all.
> In addition all CDI object implementations have to extend 
> PLatformObject, it is not necessary to add IAdaptable to CDI.
>

Sounds good, but then the interface now carries Eclipse interfaces.
Before it was stand-alone, making the change breaks the rule.

public interface ICDIObject extends org.eclipse.core.runtime.IAdaptable
{ }

What are the advantages? Any other ways? 
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev


--
The 2006 ARM Developers' Conference, October 3-5, Santa Clara, US 
Join ARM and its technology and tools Partners from around the world at the only industry event for developers of ARM Powered(R) solutions. 
http://www.arm.com/developersconference/


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Back to the top