Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Multi-core Working Group

On 10/05/2010 12:07 PM, Alexiev, Dobrin wrote:

My comments in-lined:




-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Tuesday, October 05, 2010 1:57 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Multi-core Working Group



>> Dobrin:

The part that goes into platform, I got that.

But I don’t quite get how do we deal with DSF and non DSF and still rely on flexible.

May be you can explain there more…


Standard Debug Model also had adapters written for the flexible hierarchy API.  These adapters have issues especially wrt. extensibility.  I think it should be possible to write a better framework from which standard model as well as DSF adapters could be derived from. 

What I would really like to see is an improvement on flexible hierarchy

APIs and on DSF's View Model and I would like to pull some of the ideas

from Eugene's TCF UI integration as well as things I've learned while

working with Patrick on the Breakpoints view integration.  The difficult

part is that a complete debugger UI integration has a lot of

requirements.  Some of these requirements are obvious (e.g. content of

labels, etc.),  but others are much more subtle (e.g. the need to

retrieve data from services in blocks).  Blindly rewriting this UI

integration is guaranteed to generate a lot of regressions.


Therefore, IMO a pre-requisite to any major redesign should be to write

unit tests that verify the operation of the views.  I've been slowly

working towards this goal by creating a framework and tools to test view

operation, but at my current pace I doubt I'll get there alone any time

soon.  If we get good test coverage we should be able to collaboratively

and safely evolve the UI integration into something more general that

then could be pushed into platform.  Then we could more easily ask for

UI features in platform that improve multi-core debugging workflows for



>> Dobrin:

Pawel, can you explain more what level of testing you are referring to?

Is it some kind of UI test tool, something generic, or tailored more toward flexible views?


I believe in unit tests which test a component in an isolation.  So if we're going to write tests to validate DSF view integration, I think we'll need to write some service stubs, then drive the view and validate that data in the view is correct.  I did something like this recently when I refactored the formatted values utility.  The new tests are in org.eclipse.cdt.tests.dsf plugin in org.eclipse.cdt.tests.dsf.vm.FormattedValueTests.

Also, in the past there was talk about pushing down the flexible viewers to JFace?

Is this something that may happen in the future, Eclipse 4 may be?

It will happen if we make it happen.  Having flexible hierarchy APIs be provisional for so long has been a major difficulty.  It also means that in practice this API is not so provisional anymore because so many people rely on it (just like Google mail has been a "beta" product till very recently even though millions of people have been using it).  Also, I don't think really E4 is going to have much impact on Debug. 







On 10/05/2010 09:38 AM, Doug Schaefer wrote:

> As for which debug platform, you can focus on DSF since that's

> probably where the need is more. If there are things that more

> naturally fit in debug platform that could be applied to all of them,

> then I hope we can at least architect it that way so we can implement

> it in CDT and push it down later. And if it can't be done that way,

> then let's add it to the list of things we need to from the platform

> team. We have their attention at the moment.


> On Tue, Oct 5, 2010 at 11:01 AM, John Cortell<rat042@xxxxxxxxxxxxx>  wrote:


>> I also will be contributing to the wiki page this week.


>> As for the layers question, here's my take.


>> At the end of the day, we are talking about adding features, not just

>> plumbing. The charter of the working group should be to add multicore

>> features to CDT, not the platform. That said, it's very unlikely we'll be

>> able to get some of these capabilities properly implemented without

>> enhancements in the platform. Hopefully, Pawel will be able to help us on

>> that front.


>> The next question is: to what debug infrastructure in CDT should these

>> features be hooked up to. Unfortunately, it looks like we now have three to

>> consider: CDI, DSF and TCF-debug. In theory, we should look at implementing

>> the features in a way that could be plugged into any or all of these. The

>> problem there is that doing so requires an additional layer of abstraction,

>> which complicates the design, and introduces, dare I say, yet another kind

>> of debug layer within CDT.


>> John


>> At 09:42 AM 10/5/2010, Alexiev, Dobrin wrote:


>> Thanks Mark for initiating the multicore discussion and setting up the wiki.


>> Over the next few days I'm planning to fill up some of the use cases and

>> requirements for the top level features you already outlined.

>> I hope many people will get involved at that stage...


>> At this point I'm pretty puzzled is which layer these feature should belong:

>> platform debug, flexible, CDT, CDI, DSF, TSF, etc.

>> Anyway, I'll continue my wandering on the new wiki...


>> Regards

>> Dobrin


>> -----Original Message-----

>> From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On

>> Behalf Of Marc Khouzam

>> Sent: Sunday, October 03, 2010 10:26 PM

>> To: CDT DEV (cdt-dev@xxxxxxxxxxx)

>> Subject: [cdt-dev] Multi-core Working Group


>> Hello,


>> at the CDT Summit there was a lot of interest around bringing Multi-Core

>> Debugging to the CDT.

>> I use the wording "Multi-Core" to denote a multi-node debugging session,

>> where multiple

>> cores, multiple boards, multiple targets, etc, can be debugged.


>> We got an impressive demo from TI (Dobrin and Patrick) about the work they

>> have been doing in

>> that field.  They showed a working implementation of the following features:

>>    - Grouping of debug-view elements

>>    - Debug operations (step, resume) on groups

>>    - Hiding of debug-view element types

>>    - User-selectable debug-view layouts

>>    - Debug-view hierarchy configuration in the launch

>>    - Pin and Clone of debugger views


>> Many summit participants expressed their interest in seeing such features be

>> part of the CDT,

>> and were open in helping make Multi-Core Debugging a reality for CDT (you

>> know who you are :-)).

>> To make this happen, I suggest the following:


>> - forming a Multi-core Debugging working group

>> - holding regular conference calls to discuss division of tasks, progress,

>> issues, etc

>> - dividing the effort into manageable, self-contained features

>> - establish clear targets for the next CDT release

>> - get commitments from interested parties on the work they can contribute


>> To make this effort public, I have added a "Working Groups" section to the

>> bottom of the

>> CDT wiki, where people can follow and contribute to this work.  We'll use

>> this page for

>> conference-call details, minutes-of-meetings, and other relevant

>> information.



>> This first email is meant to get the ball rolling and hopefully get

>> different people/companies

>> to discuss internally how much they will be able/willing to contribute, and

>> what their goals

>> are.  This work is an effort to take CDT Debugging to a new level, but also

>> an opportunity

>> for companies that already provide Multi-Core debugging to have their say in

>> the direction

>> the open-source community will take.


>> I personally will be absent for the month of October so I haven't planned a

>> first conference

>> call.  If people want to get started before November, please go ahead.  If

>> not, I'll schedule

>> something for the second week of November.


>> Comments and suggestions on this approach are very welcomed.


>> Take care.


>> Marc

>> _______________________________________________

>> cdt-dev mailing list

>> cdt-dev@xxxxxxxxxxx


>> _______________________________________________

>> cdt-dev mailing list

>> cdt-dev@xxxxxxxxxxx



>> _______________________________________________

>> cdt-dev mailing list

>> cdt-dev@xxxxxxxxxxx





> _______________________________________________

> cdt-dev mailing list

> cdt-dev@xxxxxxxxxxx





cdt-dev mailing list


_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx

Back to the top