Thanks,
Mikhail
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
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
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
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
|