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
|
