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