I'd love to see lldb support. Hearing good things about it. I don't know the M2M interface to it but assuming the protocol is clean, it shouldn't be hard to integrate. Other than a lot of work that is.
Doug.
From: xgsa
Sent: Saturday, July 6, 2013 4:52 AM
To: CDT General developers list.
Reply To: CDT General developers list.
Subject: Re: [cdt-dev] Re : Re: Adding a profile tool to a standard CDT toolchain
As a regular CDT & VS user I can say that advantages of writing code in CDT definitely outweigh the
limitations of debugging with it, so I prefer to use and really love CDT. Thank you guys for working on it!
>From my experience the main usability problems comes not from CDT debugging support (DSF at least), but from gdb that is used behind the scene. We have a quite big C++ project with
a few dozen of shared libraries and gdb performance is not as good as of VS debugger. In addition unfortunately gdb itself often crashes during the debugging session, so sometimes I have to debug not only my application, but also gdb itself. In this connection,
I am wondering whether there are plans about lldb support. Or at least are there any difficulties expected to implement it (except a lot of work, sure)?
There are also a few things to improve in CDT debugging support. That most issues are related to Variables & Expressions views and possibly
affect the Eclipse Platform rather than CDT itself, however as an ending user I compare the complete usability of IDE. Here are a few items:
Something similar to VS visualizers feature [1]. VS has a nice feature that allows to visualize the value of a variable of some type with a custom GUI (there are a few built-in visualizers, but they could be easily extended with user plugins). It is like
gdb pretty printers, but work on GUI level. For example separate dialog for examination of variables with long multiline strings or XML/HTML content viewers (BTW currently viewing long strings is almost impossible). Taking into account that gdb has a python
support, this feature could be really flexible.
GDB errors handling in Expressions view. When I add an invalid _expression_ (e.g. variable) to the view I am getting "Error: Multiple errors reported.", but as I can see in gdb traces console, gdb itself returns "No symbol \"b\" in current context." and "-var-create:
unable to create variable object". The refresh button directly in the value column of the view would be also helpful, but probably it is a Platform (not CDT) issue.
Hover for the variable values in Variables & Expressions views on Linux. Often the value of the variable or _expression_ does not fit into the value column. In such cases on Windows the
hover is shown. Probably it is a common issue of SWT or even GTK (that is used by SWT on Linux), but I really miss it especially here.
Hot key for "Move to line (C/C++)" action. Not very important, but a useful improvement.
Yes, as Java programmers, we don't get to use the CDT debugger very much. Even less get exposed to the other debuggers such VS.
It would be great to get user feedback on what is missing in the CDT debugger.
Marc-Andre had mentioned that we are missing the ability to show the return value of a method automatically. That would be
a great feature to have.
Are there other things that an experienced VS user misses from CDT debug?
Thanks
Marc
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc-André Laperle Sent: Wednesday, July 03, 2013 1:36 PM To: CDT General developers list. Subject: Re: [cdt-dev] Re : Re: Adding a profile tool to a standard CDT toolchain
Hi Guy,
That's good to hear! I find this comment intriguing: "(At least for writing code not debugging)". Are you saying that because you feel some features are missing when debugging? I'm sure the debug guys would appreciate feedback from someone coming from Visual
Studio (perhaps in a new thread).
Yet I have to say that I really love Eclipse and all its capabilities and architecture...
For 25 years I have worked only with Visual Studio IDE. From 4.0 up to 2012 and C++. I couldn't believe there was a better IDE than Visual Studio or C++ language. Until I switched job and had to work with Eclipse and Java..! After 20 years with almost
the same IDE I struggled a lot and couldn't find the IDE tools I wanted! It took me a year...Helped by 25 years younger developers than me to patiently bring me to a point were I was wowed by all the capabilities of Eclipse! I Learned a lot both at the coding
and architecture level. And once I mastered Eclipse IDE I wouldn't want to go back with VS (At least for writing code not debugging)! I became a more proficient coder with Eclipse and really enjoyed the coding experience with it.
Since Microsoft released Visual 2012 I really hated what they did with the IDE. Thousand of developers are crying to Microsoft telling tell how they hate what they did to their beloved IDE.
So I hope that Eclipse CDT IDE will grow in architecture and coding stability. Its a great IDE. Thought that I believe much work is left to do for that they seems to be very close to bring the CDT to maturity.
After much digging in the CDT code I have progressed and I am now able to have the profiler tool kick-in with the appropriate inputs type and output target. However I am left with a feeling of something unfinished regarding how
the output types (Primary or secondary) can be defined and are processed up to the command step building. For example I don't see how you can really produce many outputs (primary and secondaries) from a single tool since the command line pattern have only
one ${OUTPUT} dedicated to the primary output.
I have nonetheless be able to bypass this problem by custom command line generation and using option definition. However I feel it shouldn't be that hard.
To have my profiler step builder created and executed I have had to solve an issue for which I have created a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=412146 The calculateOutput method of build description wrongly
uses the tool outputs file extension attribute to create the resource outputs of any outputType associated to the tool. This prevent the build manager to resolve the appropriate build steps.