Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] DSF/CDI Launchers weirdness


TCF is extremely important to Freescale. I think what you're overlooking is the fact that gdb/mi is not a first choice for some vendors. TCF is basically an alternative to gdb/mi--one that is designed for extensibility and distributed debugging solutions. I see TCF being to gdb/mi what DSF is to CDI--it's a better mousetrap, and it's one that Freescale is investing heavily in. I, for one, am happy to see a growing interest in it.

What does it bring to CDT users? Nothing. What does it bring to CDT adopters? A lot. Built-in support for TCF opens a huge door for companies wanting to stay away from gdb and the MI protocol and use a more sophisticated run-control framework that's actively being adopted by numerous tools and silicon vendors. And if we provide a wider door, that likely means more companies adopting CDT, and that's good for CDT as a whole, including its non-commercial end-users.

Also, DSF benefits from TCF in that TCF represents a second real-world backend. DSF needs to prove that it is not gdb-centric and have safeguards to ensure it stays and grows that way. The only way it can do that is by successfully supporting additional backends. Felix and Eugene have already expressed (at the BOF) concerns about DSF. While that is troublesome, it reinforces how much we really need something else to prove DSF. Utlimately we want a debugger framework in CDT that not only works with gdb and TCF, but can be joined with any backend that any tool vendor may have or want.


At 09:16 PM 4/13/2010, Marc Khouzam wrote:
First let me say I think Pawel's note was quite inspiring. Well written Pawel.

Now, I've been meaning to ask: why the focus on TCF? What will it bring the CDT users, that it is mentioned in every second email? I'm asking honestly. I mean, we have a debugging framework. We can do remote debugging on a bunch of targets. What is TCF
meant to do for CDT?

Pardon my TCF ignorance.


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer [cdtdoug@xxxxxxxxx]
Sent: April 13, 2010 2:47 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness

Great note Pawel. Good lessons indeed. My grand vision for everything I've ever done on the CDT is to make the version people download for free as great as it can be. So when a customer looking at Wind River Workbench (or place your product here) says, "Yeah, you have CDT support. Good. I've used it, it's awesome." Unfortunately the state of things today is more like "Geeze, you say it's based on CDT but it doesn't look at all like the CDT I know".

I firmly believe we need to make the CDT awesome for both it's users and for the adopting vendors to address both those issues. CDT's indexer based features are pretty good at both. CDT launch is probably the worse at both. Build is somewhere in between, good for users, not so much for vendors.

BTW, I firmly agree with you on TCF. That's why EDC quickly becomes important in my picture as the TCF/DSF link.

On Tue, Apr 13, 2010 at 2:26 PM, Pawel Piech <pawel.piech@xxxxxxxxxxxxx<mailto:pawel.piech@xxxxxxxxxxxxx>> wrote: I think this is a fascinating discussion and I hope that as long as we refrain personal attacks and focus on constructive criticism it's OK to use our internal voices ;-)

>From my point of view I feel that we've committed the sin of a "grand redesign" against the CDT debugger.

A little background: I really enjoyed the Uncle Bob keynote<> at EclipseCon, so I searched more on the speaker and found this video<> along the same lines as the keynote. There's a hilarious passage in the video where Uncle Bob talks about the grand redesign which goes like this: First the developers realize that their product is crap so a bunch of "architects" decide that it's time to throw the whole thing away and start over clean. They form a tiger team to work on the new project. Meanwhile the rest of the developers are stuck supporting the old product and end up hating the tiger team. But the punch line is that the old product is not a static, it keeps changing so the new and the old products get into a race for features (sound familiar?). By the time the new product catches up, the original members or the tiger team are gone and a newer tiger team forms which decides that the old "new product" is actually a bunch of crap and they need to start over.

We say that "CDT is a product" ("Eclipse is a product") is a myth, because we don't want to take responsibility for something that we're not paid to support. I say that CDT is a product, because user's perception is reality. It is a product of our communal effort, which actually amounts to a lot more in resources than most of our individual commercial efforts with the IDE. We should make decisions wrt. to the CDT product with the same care that we make them wrt. our commerical products.

For Wind River's debugger product we did not take the "grand redesign" approach with DSF, or at least not the extent as we did in CDT. Instead we've been absorbing in DSF in a piece meal fashion, migrating individual views as they mature enough to meet our requirements. It's clear to me that we should have at least made an attempt to do the same with CDT's GDB integration. It may have taken a lot more work and maybe we'd not be as far along with DSF-GDB if we took this route. However, quite likely we would have had more and more satisfied users for our new technology.

Looking forward, I also see TCF as new architecture which could be disruptive to the CDT product. I hope that we take the lessons from the DSF experience and manage the TCF adoption better.

BTW, Uncle Bob's main message is that it's not the architecture that makes a great product. Rather it's its test suite. So as much as I can I'm going to try to commit my time to developing tests which will help us make sure that we don't leave our users stranded.


Doug Schaefer wrote:
To grow a community, they have to have a vested interest in contributing. This is my opinion (and I'm full of them this week it seems), but making DSF the "default" didn't bring the contributions and will actually do quite little at bringing more. DSF has been there a long time and the community has had plenty of opportunity to contribute. They just haven't had the vested interest to do so. Changing the default created the perception that we were abandoning CDI, and that is what created the need. And, of course, once DSF-GDB is at parity, I fully anticipate that need will be gone again.

I do see a need for better target management, something we talked about years ago before DSDP was created and the unfortunate (my opinion again) decision to use RSE was made. TCF is the technology that people seem to be gathering around today. That is the next ground where I see we can grow a community. Of course, I don't expect the community with a vested interest in gdb to come assist with that. And that's fine. I don't have a vested interest in gdb either.

I'm probably using my inside voice too much here, but I want people clear on where I stand on this, so you can understand why I'm prioritizing the work I'll be doing.

On Tue, Apr 13, 2010 at 1:00 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> wrote:
Doug,  I'm really glad to read your last email.
I agree (and am kind of bummed) that the efforts on debug are being pulled from all sides without a clear focus on usability. My internal customers will also want to have better usability and I'm sure I could convince my management to get some time on it.

However, I strongly believe that if we want to get more help from the community for debug we need to get more people exposed to DSF. That is my motivation to work so hard on the feature-parity issues. Already the effort has paid off as we've been getting many new patch contributions (in fact, having time to review them has proved a pleasant challenge). I feel we need to continue in those steps to build a stronger community for DSF. This should lead to more fixes, more features, more stability and more usability, eventually.

Of course, I know you are fully aware of all this, and in fact, you are one of the people that thought me about open-source and community. I'm just writing this to try to explain my current priorities.


From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>] On Behalf Of Doug Schaefer
Sent: Tuesday, April 13, 2010 11:02 AM
To: elaskavaia.cdt@xxxxxxxxx<mailto:elaskavaia.cdt@xxxxxxxxx>; CDT General developers list.

Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness

Yes, I am wishing for an ideal world. My problem is that such an ideal world wouldn't be that hard to implement. My perception is that everyone is fighting for their favorite debug integration solution versus the general good of the CDT user. That's harsh, but we do talk way more about things like parity than usability. As I switch my focus to TCF and dive deeper into the debug world, maybe that'll open up bandwidth for me to finally fix it next year.


On Mon, Apr 12, 2010 at 3:16 PM, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx<mailto:elaskavaia.cdt@xxxxxxxxx>> wrote:
In ideal world that would be fine, so in this world we just replace
backend from CDI to DSF
and all features are only better and all bugs are fixed. Since it is
not that ideal we have no
choice but to involve user in the choosing - new features but some old
features not working and more bugs,
or old and more robust but less features.

On Mon, Apr 12, 2010 at 3:11 PM, Doug Schaefer <cdtdoug@xxxxxxxxx<mailto:cdtdoug@xxxxxxxxx>> wrote:
> My hope is that when the user hits run, it never asks him for anything, it
> just runs a local application determined by the context of the selection and
> assuming the application can run locally, which we should also be able to
> determine. There should never be a question on what debugger integration to
> use for run because it doesn't matter.
> I think the same should be true for Debug. We should be able to tell from
> the context of the selection what debugger to run. And that decides what
> integration to use, not the other way around. This is something I've stated
> before, and I still stand by it.
> I just think we've hijacked launch configuration types for debugger
> integrations. There should be only be one for Local Applications, and the
> choice of debugger integration is further down the pipe. We should never put > the choice of debugger integration into the face of the user. There's no way
> they can understand the choice.
> On Mon, Apr 12, 2010 at 2:23 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>>
> wrote:
>> > -----Original Message-----
>> > From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>
>> > [mailto:cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>] On Behalf Of Doug Schaefer
>> > Sent: Monday, April 12, 2010 2:18 PM
>> > To: CDT General developers list.
>> > Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness
>> >
>> > I find the whole thing a bit weird. What this is showing is
>> > that the Eclipse Launch system, didn't anticipate that there
>> > would be multiple launch configurations types for a given way
>> > of launching. As there shouldn't be more than one config type
>> > to "Run" a C++ Local Application (they all do the same
>> > anyway, no?), there probably shouldn't be more than one
>> > config type to "Debug" a C++ Local Application. We've
>> > abstracted at the wrong level and that's just confusing as
>> > hell. Our users won't get it. And our vendors still won't use
>> > what we provide.
>> The terminology always confuses me so I might have mis-understood
>> what you meant, but here goes:
>> We only have one launch configuration type for Run:
>> "C/C++ local application".
>> After you've chosen this launch config type, you have to
>> choose which debugger integration using the hyperlink at the
>> bottom of the launch tabs.
>> For Debug, it is not great but necessary.
>> But for Run?  Do we really need to have that extra step?
>> I say we have a single launch delegate when using Run.
>> Does it make sense?
>> >
>> > Sorry, just venting, and a bit sad that the situation hasn't
>> > improved any in 7.0. It's still quite a mess.
>> >
>> >
>> > On Mon, Apr 12, 2010 at 2:09 PM, Marc Khouzam
>> > <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> wrote:
>> >
>> >
>> >       I think the problem becomes visible because you have EDC.
>> >       When I don't have EDC and I select Run As, there is no prompt
>> >       and the program launches using CDI.  This is fine
>> >       because there is actually no debugging going on.
>> >
>> >       Once you have EDC, I believe the platform no longer knows
>> >       which between CDI and EDC to choose, and that is why
>> > you get the prompt.
>> >
>> >       So, maybe adding support in DSF-GDB for Run, may not be
>> > the right solution.
>> >       Do we really want to have the user need to choose a
>> > debugger integration
>> >       even for Run?  Why choose between CDI, DSF-GDB or EDC,
>> > when there will
>> >       be no debugging?
>> >
>> >       How about a single launch delegate for Run, for all of CDT?
>> >
>> >
>> >       > -----Original Message-----
>> > > From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> >> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>] On Behalf Of
>> > Alena Laskavaia
>> >       > Sent: Monday, April 12, 2010 12:39 PM
>> >       > To: Pawel Piech
>> >       > Cc: CDT General developers list.
>> >       > Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness
>> >       >
>> >
>> >       > Well it has EDC there too in the list for Run. I
>> > don't know if it is
>> >       > different but it technically I pick EDC for run
>> > instead of standard
>> >       > launch.
>> >       >
>> >       > On Mon, Apr 12, 2010 at 12:35 PM, Pawel Piech
>> > > <pawel.piech@xxxxxxxxxxxxx<mailto:pawel.piech@xxxxxxxxxxxxx>> wrote:
>> >       > > This appears to be a bug in the multiple launchers support
>> >       > in platform.
>> >       > >  Could you file it as a bug?
>> >       > >
>> >       > > I think the correct behavior would be for the launch
>> >       > framework to use CDI
>> >       > > without prompting you whenever you select the run.
>> >       > > -Pawel
>> >       > >
>> >       > > Alena Laskavaia wrote:
>> >       > >>
>> >       > >> I was playing a bit with debugger lately and work flow is
>> >       > really awkward
>> >       > >> for me.
>> >       > >> I don't have official build I am running from the trunk
>> >       > but what I see is
>> >       > >> weird.
>> >       > >> So looks like DSF does not have a "Launcher" (the
>> > stuff you switch
>> >       > >> using link in the bottom) for Run
>> >       > >> configuration, but does for Debug. So I have to pick
>> >       > different ones for
>> >       > >> Run
>> >       > >> and Debug. So I compile my app and do Run As->Local C++
>> >       > App - and it gives
>> >       > >> me list which does not include DFS - so I pick standard.
>> >       > When I debug
>> >       > >> I have to do it again to switch to DSF. If I do opposite -
>> >       > pick DFS from
>> >       > >> Debug -
>> >       > >> when I do Run - my launch for run - does not do
>> > anything, cannot be
>> >       > >> terminated and
>> >       > >> deleted, and if I open launch configuration it shows that
>> >       > I use DSF -
>> >       > >> which is not in the
>> >       > >> list if I click on link.
>> >       > >>
>> >       > >> Is it expected behaviour?
>> >       > >> _______________________________________________
>> >       > >> cdt-dev mailing list
>> >       > >> cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
>> >       > >>
>> >       > >>
>> >       > >
>> >       > >
>> >       > _______________________________________________
>> >       > cdt-dev mailing list
>> >       > cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
>> >       >
>> >       > _______________________________________________
>> >       cdt-dev mailing list
>> >       cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
cdt-dev mailing list

cdt-dev mailing list


cdt-dev mailing list

cdt-dev mailing list

cdt-dev mailing list

Back to the top