| Re: [cdt-dev] Multi-core Working Group |
|
My comments in-lined: Thanks Dobrin -----Original Message----- 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. >> Dobrin: I believe many of the
features we were discussing (filtering, grouping) makes sense for Java
debugging too. 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. >> 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… 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. >> 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? 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? 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 > _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |