Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] July Conf Call notable items

Doug Gaff tells me that this plugin is indeed clear to go to open source, so I just need to add a copyright statements and post it to bugzilla.  Is there a particular bug I should post it to?
And yes, we can certainly talk about this tomorrow.
Cheers
Pawel

Mikhail Khodjaiants wrote:
We would need it quite soon. I am planning to come up with something by the end of August. And I have some technical questions. Is it OK to discuss it at your conference call tomorrow?
 
Thanks,
Mikhail  


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: 09 July 2007 17:57
To: CDT General developers list.; Gaff, Doug
Subject: Re: [cdt-dev] July Conf Call notable items

This is very good news.  Porting our disassembly editor to CDT is still a planned item.  Perhaps we could post our whole disassembly implementation for you to use as a reference or a base to refactor from.  We could collaborate on the API to the back end to make sure it works well for DSF and CDI and I think we'd help each other out quite a bit. 
The only thing in the way is the IP red tape.  I believe (although I'm not certain) that the code in question has already been blessed by Wind River to be released to open source, Doug Gaff can comment much better on this.  Once we can confirm this, we can submit our disassembly plugin to bugzilla, but it will then have to go through Eclipse IP review, since the sloccount on the plugin in question is 8,141.
-Pawel

Mikhail Khodjaiants wrote:
Thanks, Pawel. I haven't followed the DSF progress recently, is there already an implementation of the disassembly view or you are just planning it?
The reason I am asking is that we (ARM) are about to start working on the disassembly view and the requirements are basically the same that were discussed a year ago at DSDP DD conference calls. We are planning to contribute it to CDT if the community agrees. If we coordinate our efforts with DSDP, both projects will only benefit from it. Are you interested in doing it?
Regards,
Mikhail


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: 06 July 2007 18:28
To: CDT General developers list.
Subject: Re: [cdt-dev] July Conf Call notable items

Since most if not all CDT debugger actions act against the standard debug model extensions, I believe we can integrate DSF with existing CDT views and actions without much trouble.  If we run into problems we will file patches.  One exception may be the disassembly view(editor) which will probably require a new API and a CDI implementation.

Cheers
Pawel

Mikhail Khodjaiants wrote:
Hi Pawel,
My questions was more about the debugger related UI components (views and actions) we currently have in CDT and how these components would coexist with DSF. My concern is that if DSF contributes similar views and actions we will have duplicates which is definitely not a good thing. What do you think? 
Regards,
Mikhail


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: 06 July 2007 17:31
To: CDT General developers list.
Subject: Re: [cdt-dev] July Conf Call notable items

Doug Schaefer wrote:

Mikhail K was interested in our plans for integrating DSF into the core CDT. I guess, in summary, my plan is to move the host development support to whichever framework works best and has the most contributors working on it. But the goal is to support both DSF and CDI and allow tools integrators to make the choice. And that includes ensuring the two play nicely together.

This brought up a question I have. Is anyone really working on making sure host development works? I did a lot of work in CDT 4 to make sure MinGW worked and to help Cygwin along. I will likely stop working on cygwin in the future since my efforts there will be on supporting the CDT for Windows distribution which is based on MinGW. I’m not sure anyone is working on making sure Linux tools integrations continue to work, although that is probably the easiest and we’ve been lucky enough that there aren’t many issues there. I do know we have a lot of issues on Mac OS X, which does make up a significant and growing part of our community. All of the committers are focused on making sure their commercial tools integrations continue to work, which they have all the right to. But how do we make sure the problems that the community is having with host development get addressed. Finding contributors with vested interest in these platforms would be the best approach. Linux should theoretically be easy, but I’ve almost given up hope for Windows, thus the CDT for Window distro to help focus effort there, and I have no idea about Mac…

We decided that for reference implementation of DSF that we will focus solely on the Linux platform running the latest version of GDB.  However, our intention is to make it possible to create platform-specific (and even version-specific) GDB integrations that mostly reuse common components, but which can be maintained independently from each other.  Hopefully this will make it easier for the community interested in a specific platform to take ownership of maintaining it, while keeping the core implementation free of strange legacy workarounds.

Cheers
Pawel

A reminder to register for the CDT Summit, where this debug issue will be likely front and center. We need to make sure we invite the Platform Debug team as well.

We continue to have no requests to branch off the CDT 4.0.1 work. Until we have one, HEAD will continue to be the 4.0.x stream.

Cheers,

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com


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

--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.


_______________________________________________ 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