Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Re : Re: Re : Re: Adding a profile tool to a standard CDT toolchain

I don't want to be misunderstood regarding the CDT debugging experience of Eclipse Debugger tool (under Linux). I don't have much experience with it. I am working with Linux OS and Java since switching job and I have been both pleasantly surprised and also in pain with the OS.


I wouldn't say my debugging context is what a normal user would experiment with the CDT package. I am working with an application which is mainly Java based from a management and GUI point of view. It is a complex application using hundred of Java Jar libraries from third parties and Open source. The application uses databases and has near a thousand threads.


Below this Java code there is a pure streaming C/C++ real-time software doing media processing and decoding and doing communication through JNI interface. There is also proprietary code written in SIMD assembly and we are using Intel IPP library and IPP samples which itself is written is some case with pure assembly.


Imaging injecting corrupted data (purposely) to simulate a customer instable media reception into this environment and experimenting a crash deep in the IPP SIMD assembly code written by Intel. Imagine this code having stolen the EBP register that is used to walk the stack calling context of the C++ code which confuses the debugger! Well this is my debugging context.

Under Linux trying to debug this kind of issue with Eclipse Java/CDT is not an easy task. You have to start the Java JVM application under Eclipse Java debugging context then attach the JVM process to the CDT debugger with the same Eclipse instance. Debugging in this context with stability under Linux is possible yet incredibly difficult and in some cases you run into unknown issues that left you puzzled. Sometime randomly the Java debugging context and the CDT debugger seems to be struggling against each other and you cannot progress much in your debugging.


Under Windows debugging the same context issue is still difficult yet a lot less painful. You work with both the Eclipse IDE (for Java) and Visual Studio for C++. And both IDE seems to be at joy with each other. I don't remember having had any stability issues while debugging both the C/C++ and Java code into the same process under Windows. It is a great debugging experience under Windows. You also have great CRT debugging tools available to help you with issues like memory leak that integrate almost seamlessly. (Tried Valgrind under Linux with our app without success). You have the Gflags tool that interact at both your process and OS level to provide you with a great debugging context experience with complex issues. And I would say in some cases the assembly integration of VS with C++ is a much smoother experience when going into the compiler assembly code. So although our final deployment is Linux OS based all our debugging context uses Windows and its debugging tools. I am well aware that this wouldn't be possible if the application wouldn't live inside a JVM.


Overall I would say that the integration of all the tools you have under Windows for debugging purpose provide you with a context that let you find complex issues with mixed Java/C++ code and mixed Eclipse/Visual Studio where under Linux you would be in pain with Eclipse trying to deal with both Java/C++. It is not an issue with the CDT debugger per se.



Le 03/07/13, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> a écrit :

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?

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


On 13-07-03 11:56 AM, guy.bonneau@xxxxxxxxxxxx wrote:
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.
Thanks guys for the great CDT plugin.
Keep the good work.
Le 03/07/13, Joseph Henry <Joseph.Henry@xxxxxxx> a écrit :

I feel your pain Guy!!

I too have struggled through the tooling mess and custom command lines just to get a few simple outputs.

It does seem like it should be much simpler to go from initial input to final output(s).

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of guy.bonneau@xxxxxxxxxxxx
Sent: Tuesday, July 02, 2013 5:33 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Adding a profile tool to a standard CDT toolchain


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



cdt-dev mailing list


Back to the top