Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] common gdb plugin

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.


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:

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


At 07:18 AM 4/7/2010, Marc Khouzam wrote:
Content-Language: en-US
Content-Type: multipart/alternative;

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.

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 mailing list

cdt-dev mailing list

cdt-dev mailing list

Back to the top