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