Re: [cdt-dev] common gdb plugin

[John Cortell <rat042@xxxxxxxxxxxxx>]

I have yet to add a plugin, so I wouldn't mind going through the
experience (I'll no doubt need to bug you, though). Architecturally, it
really is odd that we have two sets of plugins targeting the same
debugger backend and they share zero backend implementation code. That
said, I'm not looking to centralize logic that is already duplicated.
This new plugin would be a place for future work. We still have quite a
few parity issues to tackle; I'm confident this new plugin will come in
handy. I really dislike copy-n-pasting code from one plugin into another,
but it goes beyond that. There may be actions/commands/extensions tied to
gdb; not having a central plugin in which to put them in presents a
challenge.

Marc has a valid point about the implications for CDI testing. I would
hope that as we work on parity features or we fix a bug that relies on
code in this plugin , we'll test the CDI feature, even if only
manually.

What we really need is a set of SWTBot based tests that drive the
features at a higher level and thus automatically are applicable to both
CDI-GDB and DSF-GDB--not only because it would solve this problem, but
the current low-level testing of DSF-GDB doesn't provide enough
confidence that the features work at the user level. 

John

At 08:47 AM 4/7/2010, Doug Schaefer wrote:

Sorry, I got confused with the terminology. The CDI-GDB layer is actually the debug.mi plug-ins.

At any rate, I have no objection to a new plug-in. It is work, though, to get it into the build and all the legal notices in place. We also need to figure out what feature projects to add it to.

On Wed, Apr 7, 2010 at 9:34 AM, John Cortell <rat042@xxxxxxxxxxxxx> wrote:

[correction]

between the CDI-GDB and DSF-GDB plugins. (I'm sure that was obvious, but just the same).

At 08:31 AM 4/7/2010, John Cortell wrote:

I think this is an interesting discussion, but it's tangential to what I suggested. My suggestion was for a plugin to house gdb-specific things between the CDI-GDB ajnd CDI-GDB plugin.

- gdb-isms do not belong in the base cdt debug plugin. I.e., those plugins should house things common between CDI and DSF but not gdb specific things

- the fact that the base cdt debug plugins currently house CDI is not ideal but that has nothing to do with my suggestion

John

At 07:18 AM 4/7/2010, Marc Khouzam wrote:

Content-Language: en-US

Content-Type: multipart/alternative;

         boundary="_000_F7CE05678329534C957159168FA70DEC524447A763EUSAACMS0703e_"

Sorry for the confusion.  There was no official decision to stop fixing bugs for CDI.  I should not have talked

about bug fixes, but more of new features.  If there will not be any new features in CDI, then copying the

code might be a sufficient solution, to allow the copied DSF code to evolve with new features.

But then bug fixes would have to be duplicated...

 

Tough call.  I'm ok with either one, if someone wants to take the time to move things around.

 

Marc

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants

Sent: Tuesday, April 06, 2010 9:52 PM

To: CDT General developers list.

Subject: Re: [cdt-dev] common gdb plugin

On 06/04/2010 8:17 PM, Marc Khouzam wrote:

In fact, if we are still in agreement that CDI is no longer being evolved, duplicating the code would

not be so bad since we would not change the CDI side of it anymore.

I realize that in reality, fixes are still applied to CDI though, so duplicate code is not a great thing.

Do we believe this trend will slow down?  That would be a way to help make this decision.

Marc, I probably missed the call when the agreement was announced. Many companies are still shipping products based on CDI and it's a big investment for them to switch to DSF/GDB. If we stop fixing bugs that's not going to force them to switch to DSF. They will simply copy the source code and will try to fix the problems themselves.

I understand you having been in the similar situation before. You are now the only person who works full time on DSF/GDB and if Ericsson decide to stop  supporting it then what?

Doug, you can pretend that the CDI is not there, but it is there :)

_______________________________________________

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