CDT R1.0 Release - Friday Mar 29, 2002 This document is intended to point out what's new since CDT R0.5 as well as known issues with the R1.0 Release. These issues will be addressed in future releases. HIGHLIGHTS OF WHAT'S NEW SINCE CDT R0.5 --------------------------------------- DEBUGGER - Debugger now able to locate DLL source - Editing the content of a Storage Monitor supported - Fixes to the operation of the GDB Console - Halting a multi-threaded application supported - Monitoring of template variables supported. - Updated Debugger Help VIEWS\UI - New Declarations Browser (support for drilling down in C/C++ Object Views) - Multiple Selection support for actions in C/C++ Projects view - Enhanced command integration with C/C++ Projects view - Output View enhancements (Shell & Standard Input Support Added) - General View enhancements (improved view selection, performance, view enabling\disabling) - New icons REMOTE PROJECTS - Detection & Cleanup on severed remote connection - UTF-8 data communication layer - Performance improvements in file transfer and project replication - Support for remote command specifications AUTOCONF SUPPORT - Streamlined Autoconf workflow - Addition of Autoconf preference page. C/C++ PARSER - Significant fixes to problems that prevented some /usr/include headers from being parsed properly. - Ability to Cancel Parse Jobs - Various performance improvements HELP SYSTEM - Updated User Documentation - Filtering Support for System Help Search. - Topic Indexing for HTML System Help KNOWN ISSUES WITH CDT R1.0 -------------------------- This list is not complete, please refer to the CDT Bugzilla database at http://bugs.eclipse.org for a comprehensive and up-to-date list of known bugs. Project Issues (Local and Remote) --------------------------------- 1. Some memory issues have been reported when working with large projects. 2. There are some timing issues with some asynchronous actions that can result in the UI not realizing that the action is finished. One symptom of this is a Progress Bar that keeps working. 3. Markers (Breakpoints, Bookmarks, Error Results etc) have minimal support when working with Remote Projects. They are not persisted, and are not visible in the typical Eclipse views (Task List, Search Results). Parsing Issues -------------- The parser has been written to handle both C and C++ and is really a work in progress. There are constructs or features of both languages that the parser does not currently handle gracefully or at all. When the parser encounters some code that it can't handle, it tries to skip over the problem and continue parsing. When it does this, it creates Parse Exception objects that will appear intermingled in with the other C/C++ objects when looking at the Details view of a Parsed File... Here are some of the most common known problems: - There are several known issues with UI responsiveness during a large parse job. For now, once a large parse has been started, it is best to wait until the status bar has disappeared before trying to access the parse information in the UI. The status bar actually disappears when a "first-level" parse of all files has been completed. There is still more work being done by the parser at this point. For some very large parse jobs, UI responsiveness may not return to normal until the parser is completely finished. Currently the only way to know when the parser is completely finished is to check the CPU usage for the java vm used to start eclipse, and verify that it is near 0. The performance of the parser is is one of the key areas that will be addressed in future releases of the CDT. - When parsing a large project, there is a potential to use a large amount of memory. If you encounter memory problems create a batch\script file that starts eclipse (so that we can have control over the command-line parameters sent to the JVM. A typical script would look like this: java -Xms100m -Xmx200m -verify -cp startup.jar org.eclipse.core.launcher.Main The -Xms and -Xmx set the minimum and maximum memory size that the JVM is invoked with. (We will be looking into memory issues in upcoming releases) - Persistence of Parse Information for large remote projects has been known to not work, and might actually cause other problems. - Known language limitations: - Some variable\function\struct names are not shown correctly. Some of the more common problems include Operator Overloading, and C++ Nested Name Specifications (A::B::C) - Some macro replacements will not behave correctly - Expression Evaluation is currently turned off in the preprocessor, so #if, #ifdef etc, will not actually conditionally include source. Since we don't yet provide a way for a user to set macro values we felt that it was a better idea to parse all source. Depending on how your source is structured, this can cause duplicate objects or affect the accuracy of parse information. - If a function is forward declared, both the definition and declaration will appear as separate objects - Some casts are not parsing properly - C++ Parsing is has not been well exercised so there are likely problems with templates, namespaces, etc. Command Launcher View -------------------- 1. The Command Launcher View requires an object in the C/C++ Projects view to be selected. If you find that the Run Button in the Command View doesn't appear to work, goto the C/C++ Projects view and select a Project or File and try again. Command Specifications View --------------------------- 1. Users may need to click on the project to set the focus in the navigator before adding/removing command specifications within that project scope 2. When creating a command specification using the wizard, the selected project will be highlighted and selected automatically. Changing it to another project from within the wizard will not cause the command specification to belong to the selected project. Searching --------- 1. Search results only appear for objects contained in the files of local projects. Objects contained in included files or remote projects do not show up in the search results view. For remote projects use the Output view to see the results. General View Issues ------------------- 1. For large projects, refreshing or refiltering Parse Views can be quite slow. 2. The C/C++ Projects view and the Navigator are not always in sync. The solution is to do a refresh in the view that appears not up to date. Debugger issues --------------- 1. When terminating a debug session, please avoid terminating the debug daemon. If the debug daemon is terminated, you will have difficulties starting another debug session with the daemon listening to the same port. You will get this error message: "Failed to launch the PICL UI Daemon, the port may be busy. Try changing the port in the PICL Debug preference page." To get around this problem, you can either restart Eclipe, or change the Debug Daemon port. To change the port that the debug daemon listens to, go to Windows->Preferences->Debug->Compiled Debug. 2. Some views in the Debug Perspective may not be updated properly after a command has been executed from the GDB Console. For debugger features that are being considered for future releases, please see todo.txt. Project Management Issues (autoconf and automake) ------------------------------------------------- 1. In order to make your executable debuggable, you need to edit the Makefile.am and insert one of the following lines: CXXFLAGS=-g or CFLAGS=-g 2. If your project contains source files in its top level directory, then use the "Create Programs Makefile.am" action under the "Advanced..." autoconf menu prior to running "Configure".