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
I assure you that you'll have Platform Debug group's attention for as long as needed. Though I have to admit, it's very difficult to make major innovations in any part of platform.
As far as multi-core implementation, I think there's an opening to do something new. Anything limited to DSF is going to be... well, limited. And in order to make significant UI and workflow changes we'll need to make them in Platform, so a feature limited to few implementations would not make a strong case for such changes.
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 everyone. 

Cheers,
Pawel

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.
http://wiki.eclipse.org/CDT/MultiCoreDebugWorkingGroup

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
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top