Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CDT/User/FAQ
Contents
- 1 Introduction
- 2 General
- 2.1 What is the CDT?
- 2.2 How is the CDT licensed?
- 2.3 How is the CDT Project organized?
- 2.4 How do I find out about future releases of the CDT?
- 2.5 What is the default configuration supported by the CDT?
- 2.6 Which operating systems does the CDT support?
- 2.7 Which platforms are fully supported will ultimately depend on the needs of the community, as expressed by the participation in developing, and testing for each platform?
- 2.8 Why isn't the XXX operating system supported by CDT?
- 2.9 How do I ask questions?
- 2.10 How do I report a bug or request a feature?
- 2.11 Where is this .log file that I hear so much about?
- 3 Download and Installation
- 3.1 Are there complete HowTos for setting up the CDT?
- 3.2 Which CDT build should I download?
- 3.3 Where is CDT update site?
- 3.4 I can't find the CDT download for the XXX operating system?
- 3.5 How do I uninstall CDT?
- 3.6 How do I convince Eclipse to "re-read" the configuration files?
- 3.7 I installed MinGW toolchain on my PC but Eclipse won't find it.
- 3.8 I installed Cygwin on my PC but Eclipse won't find it.
- 3.9 Which bugs were fixed in CDT 3.1.2 release?
- 4 C/C++ Project Creation
- 4.1 Creating a simple Managed C++ Project -- "Hello World on a Windows Platform"
- 4.2 Creating a simple Standard C++ Project -- "Hello World on a Windows Platform"
- 4.3 How do I create a new project using a directory full of existing source?
- 4.4 How do I create a new project using CVS?
- 4.5 How do I Import existing code into an existing project?
- 4.6 How do I work on a C/C++ Project on a remote server?
- 4.7 Can I use CDT for Android native code?
- 5 Adding C/C++ External Libraries
- 6 Editing C/C++ Projects
- 6.1 I'd like to use the code assist functionality, but it doesn't seem to work for me. I don't get anything showing up when I select CTRL+SPACE in a C/C++ source file.
- 6.2 I am using a non gnu compiler and I get the following messages: "Error launching external scanner info generator (gcc -E -P -v -dD" and "File not indexed because it was not built ". How do I get rid of them?
- 6.3 How can I add another extension to CDT so that files other than c/cpp/cc/h files are recognized as source files? My compiler needs the file extension to be "xyz", and when I open xyz files there is no syntax highlighting.
- 6.4 Search is broken
- 6.5 Why does Open Declaration (F3) not work? (also applies to other functions using the indexer)
- 6.6 I installed a new version of my compiler but old include paths of old compiler are still there under "Paths and Symbols" in project properties. I cannot get rid of them! What do I edit to remove the old paths by hand?
- 6.7 I heard that CDT can parse output of my build and set includes (-I) and macros (-D) per file but it never seems to work for me.
- 7 Building C/C++ Projects
- 7.1 When do I use the standard make feature
- 7.2 When do I use the managed make feature
- 7.3 Where are the Build menus? I could not invoke building action by clicking. However, after saving action, the project would be built and an executable would be generated.
- 7.4 In CDT 4.0 I check "Build Automatically" but my files don't get built when I save a source file.
- 7.5 Building a simple C++ Project -- "Hello World" on a Windows Platform
- 7.6 Can I see the raw compiler output? Where is this information placed?
- 7.7 I get the error 'Build error (Exec error: Launching failed)'
- 7.8 I get "make Error 127 line 0" when trying to build
- 7.9 My Compiler errors seem to be truncated or split. What is going on?
- 7.10 What causes the message 'make (e=2): The system cannot find the file specified'?
- 7.11 How do I exclude files from being built in a managed make project? I have tried setting up individual source folder in the Project->Properties panel, but the managed make seems to always include all source file in the project, regardless of the Project Paths settings.
- 7.12 Why does CDT with MinGW do full rebuilds on all of my build and launch actions although all settings suggest an incremental build?
- 7.13 Why do I get the an error saying "make: *** No rule to make target `all'."?
- 8 Debugging C/C++ Projects
- 8.1 Can I debug a process that I didn't develop in Eclipse?
- 8.2 I've been asked for 'gdb traces', where can I find them?
- 8.3 I don't see the debug preferences pages
- 8.4 How can I inspect the contents of STL containers?
- 8.5 How do I do Reverse Debugging?
- 8.6 What is the difference between Non-stop and All-stop multi-threaded debugging?
- 8.7 How do I debug a remote application?
- 8.8 How do I use multi-process debugging?
- 8.9 How can I trace my application using C/C++ Tracepoints?
- 8.10 Since the debugger is gdb, can I simply access the gdb command line interface (CLI)?
- 8.11 I'm using cygwin and when launching the debugger, it complains that it can't find the source file
- 8.12 I get the message "gdb: unknown target exception 0xc0000135 at 0x7c9766c6"
- 8.13 Other Questions
- 8.14 HOWTO debug applications which require a real terminal
- 8.15 How can I choose another debugger integration for CDT?
- 8.16 What should I do when the debugging session misbehaves?
- 9 Miscellaneous Troubleshooting
- 10 Compilers and other 3rd party tools
- 11 Working on the CDT
- 11.1 How do I get a more recent build than is on the downloads page?
- 11.2 How do I build CDT from CVS if I want an even more recent build and I want all the pieces and parts?
- 11.3 How do I export it so that it can be used with an external Eclipse installation?
- 11.4 How do I use eclipse to develop eclipse?
- 11.5 How do I modify the code and build the result
- 11.6 How do I run with my changes?
- 11.7 How do I submit a fix for a bug?
- 11.8 How do I distribute my changes to my customers?
- 11.9 How do I generate JavaDocs?
- 11.10 How do I add a CDT extension to my PDE project?
- 11.11 How do I add an Error Parser (or The project seems to build file, but doesn't parse my error output what can I do?)
- 11.12 How do I add a Cross platform debugger?
- 11.13 I am developing a plug-in that requires a parsing a c file and obtaining the information such as method signatures, parameter types etc. How can I do this using the CDT parser?
- 11.14 Missing org.eclipse.cdt.templateengine
- 11.15 CEnvironmentTab
- 11.16 What's the best way to set up the CDT to navigate Linux kernel source?
- 11.17 What are some areas that are not complete
- 11.18 In addition to submitting fixes, how else can I contribute to the CDT Project?
- 11.19 Want more FAQ related to CDT development?
Introduction
How do I contribute to this FAQ?
Simply edit this page. You will need to log in using your bugzilla username and password to gain access. If you don't have a Bugzilla account, you can create a new one.
Is it really that easy?
Yes!
General
What is the CDT?
The CDT (C/C++ Development Tools) Project is working towards providing a fully functional C and C++ Integrated Development Environment (IDE) for the Eclipse platform.
There are a number of groups contributing to the CDT; We strongly encourage interested parties to extend our work, thereby making the Eclipse CDT project a richer set of freely available resources. We are looking for contributions from the open source community in the areas of test, development, documentation, and general users who can help us ensure that the C/C++ tools work well on all the Eclipse platforms.
Our current release function includes:
- C/C++ Editor (basic functionality, syntax highlighting, code completion etc.)
- C/C++ Debugger (APIs & Default implementation, using GDB)
- C/C++ Launcher (APIs & Default implementation, launches and external application)
- Parser
- Search Engine
- Content Assist Provider
- Makefile generator
Default implementations of all interfaces and extension points will be supplied for various platforms.
The CDT is fully open-source and implemented purely in java as a set of plugins to the Eclipse platform. To learn more visit the CDT Home Page.
How is the CDT licensed?
The CDT consists of software produced by the CDT team combined with third party software developed from other Open Source Projects. The software produced by the CDT team is licensed under the Common Public License. The software designed by third parties is made available under their respective licenses. Refer to the about.html file in the root directory of every CDT plugin for specific licensing information.
How is the CDT Project organized?
Visit CDT Project Structure to find out more about the organization of CDT (History, participants, and project structure).
How do I find out about future releases of the CDT?
See the CDT/planning section.
If you wish to contribute to the development of the CDT, we welcome the opportunity to work with you. The plans will be updated to reflect the commitments made by contributors to this projects. See Working on the CDT for information on how to get started.
Release Milestones (which represent planned availability dates for Stable CDT builds) are noted in the CDT Plan Documents which can be found on the CDT Overview Page. To see the currently available CDT builds, choose from either the current official release or from the nightly builds.
What is the default configuration supported by the CDT?
This is a bit of a moving target, but currently the compiler supported (from an error parsing point of view) is gcc, the debugger interface will work with gdb 5.2.1 (or higher) and the default build command is GNU "make".
Which operating systems does the CDT support?
The CDT Framework is platform independent. It will run where Eclipse will run. However, the default implementations may depend on external applications. To follow in the Eclipse spirit of open source, the default implementations rely upon freely available open source tools, such as the GNU Tools: GDB and Make. Therefore, the dependencies on GDB for debugging, or Make for building, will require that these applications are available for the platform that the user wishes to use. References to some of the known implementations for each platform will be indicated in the sections of this FAQ that include instructions for installation, project creation and building the CDT on the various platforms.
Which platforms are fully supported will ultimately depend on the needs of the community, as expressed by the participation in developing, and testing for each platform?
The core plugins are written in Java with no native code and thus may be ported to any platform supported by Eclipse. However, some default implementations may require that other software or tools, licensed under GNU, may be required.
In general there is some version of Linux and some version of windows used by the developers on the CDT. For an exact list of supported platforms see the Downloads page.
Why isn't the XXX operating system supported by CDT?
"Supported" has a particular meaning to us. It means that on that platform we have a good level of confidence that CDT works correctly and that its function is appropriate and complete. That means
- someone has ensured that the function addresses the important use cases
- the function is exercised by regular execution of a test plan
- identified problems are tracked to resolution
- there is a recipient for user feedback
- code patches are developed as necessary to correct or extend CDT on that platform
To make this all happen a platform has an Owner - someone who accepts the responsibility to make sure those things all happen.
The Framework supports all the platforms that Eclipse does. The CDT team is responsible for ensuring that this remains true for the framework. Specific default implementations will work only on platforms where the required applications are available. The following list is derived from the initial CDT meeting in July 2002. The following companies have agreed to provide support for the associated platforms:
Platform | Company |
---|---|
QNX Neutrino | QNX Software Systems Ltd. |
Linux | IBM, Red Hat |
Windows | IBM, MontaVista with initial support from QNX |
If you have a favorite platform we highly encourage you to get involved and volunteer to own a feature that does not currently have an implementation that works on your platform of choice. See #Working_on_the_CDT for more information.
How do I ask questions?
CDT related questions that are not answered in this FAQ or the documentation should be posted to the CDT newsgroup. You will need a password. You can also use this simple web interface to browse the newsgroup. General Questions about the Eclipse SDK which includes the Eclipse Platform, JDT (Java Development Tools), or PDE (Plugin Development Environment) should be posted to the Eclipse newcomers newsgroup.
Keep in mind that these newsgroups are public, so do not include any confidential information in your questions. You should also read "How to ask questions the smart way" by Eric Raymond before participating in the newsgroups. NOTE: Please submit bugs to bugzilla, not to the newsgroups. See the How do I report a bug or request a feature? section of this document.
People will still come into a newsgroup asking questions that have been answered before and often will not provide any information about what versions they have installed, and what the problem is. You will be much more likely to get help if you provide enough information to reproduce the problem. The section on how to report a bug gives a list of some information which could be useful.
How do I report a bug or request a feature?
The CDT Project (like the Eclipse Project) uses bugzilla as its bug and feature tracking system. Entering a bug/feature report is as simple as filling in a web form on the eclipse bugzilla page. The first time you enter a bug you will need to create a new bugzilla account for yourself by providing an email address and choosing a password.
Before entering a bug report, you should search bugzilla to see if someone else has already entered a bug report similar to yours. If you find a bug report that outlines the problem you are seeing, you can simply annotate it with your comments to let the developers know that you have also hit the bug. Also you can add yourself to the CC list of the bug so that you will notified when the status of the bug changes or someone adds comments.
Once you have searched bugzilla and not found anything, you can go ahead and enter a new bug report. Please read the bug writing guidelines located on the eclipse bug reporting page.
To make your bug report more helpful include the following in your bug reports:
Environmental settings:
- 1. The build level of Eclipse that you are using. For example, "Eclipse 3.0M6"
- 2. The build level of CDT that you are using. For example, "CDT build 2.0.0.0026"
- 3. Your computer's specifications (OS version + patch level, memory, other pertinent info)
- 4. The contents of your .log file (or lack thereof). This is especially important if you get a dialog that reports an internal error. See What is this .log file I hear so much about? for information on finding your .log file.
- 5. The Java runtime or development kit you are using to run eclipse (use java -version or java -fullversion)
Problem Description:
- 1. A description of what you were doing,
- 2. A description of what behavior that you observed, and
- 3. An explanation of how the observed behavior differs from the expected behavior
Where is this .log file that I hear so much about?
The .log file is located in the workspace/.metadata directory.
The .log file is used by the Eclipse Platform to log runtime errors. It is useful to include it in bug reports because it contains stack traces that occur in plug-ins. When you report a bug, make sure to include your .log file!
Download and Installation
Are there complete HowTos for setting up the CDT?
Yes, please see
- http://max.berger.name/howto/cdt/
- http://eclipsewiki.editme.com/CDT
- http://eclipsewiki.editme.com/InstallingCDT
- http://www.cs.umanitoba.ca/~eclipse/7-EclipseCDT.pdf
- http://zetcode.com/articles/eclipsecdevelopment/
Which CDT build should I download?
The latest stable release version is available from the CDT downloads page.
Where is CDT update site?
1. There is a p2 repository aggregated with eclipse repository so it should be available with eclipse updates. It is possible to access it directly, for example for Indigo the update site is http://download.eclipse.org/tools/cdt/updates/indigo.It is updated every milestone.
2. You can take the bleeding edge updates from Hudson nightly builds (they are normally quite stable). The update site is https://hudson.eclipse.org/hudson/job/cdt-nightly/lastSuccessfulBuild/artifact/update-site/
I can't find the CDT download for the XXX operating system?
The CDT is supported on the platforms specified on the download page. The downloads are structured and named to indicate, which OS and windowing system it runs on. If you do not see your OS/windowing system combination please contact us. We are always looking for volunteers to test and support platforms.
Much of the CDT default functionality uses applications that are available on most operating systems. The CDT leverages some default system tools such as gdb (debugging), make (building). These tools are available for many platforms and if they exist on your system, there is a good chance that the default functionality will work. See Compilers and other 3rd party tools for more information
The caveat is that the operation of the CDT on some operating systems has not been fully tested and we cannot commit time to fixing platform specific problems found on these platforms. However, code submissions from developers wanting to improve the CDT will always be gratefully accepted. See Working ON the CDT for more information.
How do I uninstall CDT?
We do not currently ship an uninstaller. You can uninstall the CDT manually:
- 1. Shutdown the eclipse shell that is running CDT
- 2. Remove the CDT plugins
- Navigate to the directory where the CDT plugins are installed (typically eclipse/plugins)
- Remove the following plugins:
- org.eclipse.cdt.*
- 3. Remove the CDT metadata
- Navigate to the workspace/.metadata/.plugins directory
- Remove the following directories (if they exist):
- org.eclipse.cdt.*
- 4. Restart Eclipse
How do I convince Eclipse to "re-read" the configuration files?
Delete the following:
- /configuration/org.eclipse.osgi/manifests
- /configuration/org.eclipse.osgi/.bundledata
- /configuration/org.eclipse.osgi/.state
and restart eclipse.
I installed MinGW toolchain on my PC but Eclipse won't find it.
The following algorithm is used as of CDT 7.0 (Helios). Note that older releases may use different algorithm. That is org.eclipse.cdt.managedbuilder.gnu.mingw.MingwEnvironmentVariableSupplier if you want more details.
- 1. Look at the mingw directory in the platform install directory. CDT distributions like Wascana may distribute MinGW like that.
- 2. Try the directory above the install dir (another possible distribution).
- 3. Look in PATH values. More specifically, it tries to find mingw32-gcc.exe in each path.
- 4. Try looking if the mingw installer ran (registry.getLocalMachineValue("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\MinGW", "InstallLocation"); ).
- 5. Try the default MinGW install dir ("C:\\MinGW\\bin").
Don't forget to restart eclipse if you changed PATH environment variable.
I installed Cygwin on my PC but Eclipse won't find it.
The following algorithm is used as of CDT 7.0 (Helios). Note that older releases may use different algorithm. That is org.eclipse.cdt.managedbuilder.gnu.cygwin.CygwinPathResolver if you want more details.
- 1. Look in PATH values. Look for "cygwin1.dll" (normally under "bin/" folder).
- 2. Try to find the root dir in registry: readValueFromRegistry("SOFTWARE\\Cygwin\\setup", "rootdir").
- 3. Try to find the root dir in registry for 64 bit: readValueFromRegistry("SOFTWARE\\Wow6432Node\\Cygwin\\setup", "rootdir").
- 4. Try to find the root dir in mounts from registry: readValueFromRegistry("SOFTWARE\\Cygnus Solutions\\Cygwin\\mounts v2\\/", "native");
- 5. Try the default Cygwin install dir "C:\\cygwin".
Don't forget to restart eclipse if you changed PATH environment variable.
Which bugs were fixed in CDT 3.1.2 release?
To find which bugs were fixed in this release, run this bugzilla query: List bugs fixed for CDT 3.1.2 release
C/C++ Project Creation
Creating a simple Managed C++ Project -- "Hello World on a Windows Platform"
(Note: See these two FAQ entries to decide whether to use a Standard Make project or use a Managed Make project.)
This section will use an example to create the familiar "Hello World!" C++ program. First, ensure that you have the CDT installed within Eclipse, as described above. Open a C/C++ Perspective and complete the following steps:
- 1. Click "Project" from the menubar and ensure there is no checkmark beside "Build Automatically" -- if there is one, click "Build Automatically" to deselect it. ("Build Automatically" disables the build menus and buttons; you may want to turn it on later to avoid having to rebuild manually when modifying your projects.)
- 2. In the "C/C++ Projects" View, right click and select "New Project ..."
- 3. Expand "C++", then select "Managed Make C++ Project"
- 4. Enter a name for the new project and select "Finish". Note: you can determine the build Settings from this dialog, but we will do so later, in the build section.
- 5. In the "C/C++ Projects" view, right click and select "New" > "File". Name your file "hello.cpp" and click "Finish".
- 6. Copy or type the following text into the "hello.cpp" file:
#include <stdio.h> int main() { printf("hello, world\n"); }
- 7. Save the file.
There are several ways to initiate builds and to run the executable from the menu, toolbars, keyboard, and other objects. Descriptions of them all can be found in the Eclipse documentation. These work from the project object in the "C/C++ Projects" panel:
- 8. Right click the project panel and select "Build Project". A popup and the Console tab will show the build status. If there are errors they will show up in the "Problems " panel.
- 9. Right click the project panel and select "Run As" > "Run Local C/C++ Application". The Console tab will show your program's output. The "Debug" panel will show the exit status, or the state of the program if it failed to terminate correctly.
Creating a simple Standard C++ Project -- "Hello World on a Windows Platform"
(Note: See these two FAQ entries to decide whether to use a Standard Make project or use a Managed Make project.)
This section will use an example to create the familiar "Hello World!" C++ program. First, ensure that you have the CDT installed within Eclipse, as described above. Open a C/C++ Perspective and complete the following steps:
- 1. In the C/C++ Projects View right click and select "New Project ..."
- 2. Select "C++" in the left pane and the select "Standard Make C++ Project" (or, in more recent CDT, select "C++ Project", click "Next" and then "Empty Project" in the "Makefile project" folder)
- 3. Enter a name for the new project and select Finish. Note: you can determine the "Build Settings" from this dialog, but we will do so later, in the build section.
- 4. In the C/C++ Projects View right click and select "New" > "Simple" > "File". Name your file hello.cpp
- 5. Repeat the previous step and name the second new file "makefile".
- 6. Copy the following text into the "hello.cpp" file:
#include <stdio.h> int main() { printf("Hello World\n"); //block until user types something getchar(); return 0; }
- Now, save the file.
- 7. Copy the following text into the "makefile" file:
- Remember that makefile requires that indented lines use a <tab> character and not spaces
hello.exe : hello.o g++ -o hello.exe hello.o
hello.o : hello.cpp g++ -c hello.cpp all : hello.exe clean : -rm hello.exe hello.o
- Now, save the file.
How do I create a new project using a directory full of existing source?
If the source is accessible to the user from their desktop using the command line then it is possible to simply make the root directories containing that source as Eclipse projects. This is accomplished by invoking the New Project Wizard, selecting C or C++ and then Standard Make Project as the project type. On the next page, enter a name for the project, the deselect the "Use Default Location" checkbox. This will let you Browse to the root folder of the source tree. After setting other information and clicking on Finish, the project will be created in the root of the source folder you have selected.
The resource for the project are maintained in the remote location specified, not in the workspace folder for eclipse. Meta data for the project, such as the index for the project and the "link" to the project, is stored in the metadata directory in the workspace folder.
How do I create a new project using CVS?
If the existing source tree is managed in CVS, it is possible to use the CVS Repository perspective to "Checkout As Project" any folder in the repository. The first time this is done, a Simple Project is created for the folder. To access the features of the CDT for this project, the project must be converted to a C or C++ project using the "Convert to a C or C++ Project" project type in the New Wizard.
This does a CVS checkout of the project into the project's location (usually in the workspace).
How do I Import existing code into an existing project?
Another approach would be to create the C/C++ Project and then do an "Import"→"File System". This will make a copy of the files from the selected location into the selected folder in the project. With the copy, this approach is more wasteful and detaches the source from any control mechanism that existed in the original file location (e.g. a ClearCase view)
How do I work on a C/C++ Project on a remote server?
There's multiple different setup scenarios possible. Look at the TM and RSE FAQ#How_can_I_use_a_remote_workspace_over_SSH.3F for details.
Can I use CDT for Android native code?
Yes, you can use CDT to help you edit your C/C++ code. With NDK r4 (June 2010) it is really easy. You must choose "Makefile project/Other Toolchain" in New → Convert to C/C++ project. You should manually set the include path to follow the NDK toolchain:
${NDK_ROOT}/build/prebuilt/windows/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0/include-fixed ${NDK_ROOT}/build/prebuilt/windows/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0/include ${NDK_ROOT}/build/platforms/android-8/arch-arm/usr/include
You can build native code with CDT as part of the Android project build. You set build command (C/C++ Build → Builder Settings):
make -f ${NDK_ROOT}/build/core/build-local.mk
Please don't forget to click Apply.
In Behavior tab, remove target names from both "Build" boxes. Leave clean target for the third build type (Clean).
Unfortunately, you cannot debug your native code on Android with Eclipse/CDT. Use gdb provided with NDK. You can use ELF binary parsers of CDT to examine the libraries that are built.
Adding C/C++ External Libraries
How do I add an external library to my C++ project?
Go to Your Project's Properties by right clicking on project's name and selecting properties. Click on "C/C++ Build". Under Tool Settings Tab, click on Directories. Click on The Add Button and Select FileSystem. Select the folder with C/C++ libraries. Apply and then Ok. The new library is included.
The option commented before didn't work when I tried it. I solve it including the external library I want to add (libwsock32.a in my case) in Project->Properties->Tool Settings Tab->C++ Linker->Miscellaneous.
14:26, 18 December 2007 (EST): Neither of these worked for me under Linux. I had to open up the project's properties and go to "C/C++ Build" -> "Settings" and then hit the "Libraries" item under "GCC C++ Linker" heading in the list on the right. Then, I entered the libraries as I would in the command line ("pthread" for libpthread, etc...). (Dustin Oprea)
Editing C/C++ Projects
I'd like to use the code assist functionality, but it doesn't seem to work for me. I don't get anything showing up when I select CTRL+SPACE in a C/C++ source file.
If you fail to find a completion you expect to find, most probably this is because of a failure in parsing your source file. In this case, check that you have added the correct set of include paths to the project containing your source file.
For example, in the following code:
int main() { pr }
You should not expect "pr" to provide "printf" as a completion unless:
- You have an #include <stdio.h> in the file
- the include path to stdio.h is available in the project
- any macro's necessary to read stdio.h are set (often a missing macro will cause a system header to encounter a #error in the header file -- for example on windows using cygwin, the defining the symbol __i386__ will allow stdio.h to be understood)
There are limitations for content assist together with templates.
I am using a non gnu compiler and I get the following messages: "Error launching external scanner info generator (gcc -E -P -v -dD" and "File not indexed because it was not built ". How do I get rid of them?
In general the parser needs to know the include paths and macro definitions for each source file and the compiler built-ins before it can be parsed(the indexer is one client that will parse the files).
In CDT there is a scanner config feature that will invoke the compiler "gcc -E -P -v -dD" to ask it for the default values. This feature will also look at the output of running "make" and try to determine which includes (-I) and which defines (-D) have bee set on the command line.
Your project has been setup to use the defaults for gnu to get this info. Since you are using a non-gnu compiler, you should disable all of the discovery feature. Got to the Properties on your project and open the section "C/C++ Make project" and select the "Discovery Options" tab. Deselect the "Automate discovery of paths and symbols" and these errors will go away.
Note that you will then need to manually add the paths and symbols to the project (or you will get a lot of other parser errors). This can be done from the same dialog under "C/C++ Include paths and symbols".
How can I add another extension to CDT so that files other than c/cpp/cc/h files are recognized as source files? My compiler needs the file extension to be "xyz", and when I open xyz files there is no syntax highlighting.
There are a few places to find and set these associations. You may need to add your file extension to all of these containers to get all of the capabilities you expect:
- 1. Window > Preferences > General > Content Types. This tree associates a filename or filename pattern with its content type so that tools can treat it properly. Source and header files for most languages are under the Text tree.
- 2. Window > Preferences > Editors > File Associations. This list associates a filename or filename pattern with the program needed to edit it, if the default editor is insufficient.
- 3. Window > Preferences > C/C++ > File Types. This list associates a filename or filename pattern with its generic content type so that tools can treat it properly.
Search is broken
see below
Why does Open Declaration (F3) not work? (also applies to other functions using the indexer)
Check whether CDT has the include paths to resolve your headers: In the context menu of the project select Indexer - Search For Unresolved Includes. You can also use the Include Browser (from the Editor, Right-click > Show in > Include Browser) to see which includes have been resolved.
If your include paths are missing you can add them on Project > Properties > C++ Include Paths and Symbols > Add Include Path from Workspace.
Then rebuild the index: Select project, right-click > Index > Rebuild Index.
After rebuilding index, look at Window > Show View > General > Error Log: Hover over the "Info" entry, it shows some statistics about what it just indexed. In a reasonably well setup C project, "unresolved symbols" should be below 1% -- for C++ the value can be higher depending on code complexity (CDT still has issues with Templates and complex name lookups).
A very high number of syntax errors is often nonfatal, and may indicate language extensions such as non-standard GNU extensions which are not detected properly, or incorrect compiler inspection, or missing preprocessor macros that should be set from the Makefiles. Try discovering these by loading a log from running an actual "make" on your project (you do this in the Project Properties, Paths and Symbols, Discovery).
A nice help for finding indexer problems is enabling Window > Preferences > General > Editors > Text Editors > Annotations : C/C++ Indexer Markers. These will show up as markers in your open editors, so you'll see if the indexer had problems understanding the syntax of the code that you've just been working on. It will not reveal semantic issues.
I installed a new version of my compiler but old include paths of old compiler are still there under "Paths and Symbols" in project properties. I cannot get rid of them! What do I edit to remove the old paths by hand?
There is a bugzilla report about that, follow bug 206372. To manually fix the problem you need:
- delete file ${projectname}.sc found under ${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core
- restart eclipse.
In new CDT version (7.0.1 and 8.0) a new button "Clear" has been added on "Discovery Option" page in project properties. You need to clean entries for each language separately.
I heard that CDT can parse output of my build and set includes (-I) and macros (-D) per file but it never seems to work for me.
This feature is called Scanner Discovery, It could be tricky to set up and you may need to work around a few bugs. If you feel adventurous you can start from this:
- Create a new makefile project "Hello World".
- In project properties C/C++ Build -> "Discovery Options" select "Configuration wide" and select Discovery profile "GCC per file scanner info profile". Save the properties.
- Make sure file Hello.cpp is under the project's root.
- Create folder "headers".
- Create a make target to print "gcc -Iheaders -DHello=1 -c Hello.cpp" in the console. Make sure "Run all project builders" is enabled. For example:
- Run the make target.
After that is done file Hello.cpp should be marked with "wrench" overlay and you can check in file properties that /absolute/path/headers and Hello=1 added to "Includes" and "Symbols" on "Paths and Symbols" property page. Those entries are marked as "built-in" values.
Sometimes the entries are stubborn to appear. You can try to "Clear" entries on "Discovery Options" page, closing and reopening your project or removing temporary project files in workspace area in .metadata/.plugins/org.eclipse.cdt.make.core/
Due to many issues Scanner Discovery is under redesign, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=290631 for more information.
Building C/C++ Projects
When do I use the standard make feature
When you already have a makefile and you wish to use it.
When do I use the managed make feature
When you do not have a makefile, and do not want to write one, the managed make feature will be able to generate one for you. Note that the current CDT (1.2.1 and 2.0) generates makefiles that use GNU gcc and g++. If you are not using this compiler, (and you do not have a managed make plugin for your compiler), then you will need to use the standard make feature.
The Build Automatically flag removes the build menus. (This was proclaimed a feature and not a bug in Bugzilla Bug 71443.)
For your first C/C++ projects Build Automatically should be turned off, otherwise builds will be performed whenever a file is saved, including makefiles and header files. Doing this manually will help you figure out what is going on in Eclipse and CDT. It can also be helpful to turn it off for large projects with intricate dependencies that generate a lot of rebuild action when certain files are touched. And there are other menu items and buttons that will be enabled.
Click Projects from the menubar and ensure there is no checkmark beside Build Automatically. If there is one click Build Automatically to un-check it.
You should now be able to Build and Clean a project.
In CDT 4.0 I check "Build Automatically" but my files don't get built when I save a source file.
Edit the project properties (context menu on the Project in Project Explorer, Select 'Properties' at the very bottom) Select C/C++ Build and click on the Behaviour tab. Check 'Build on resource save (Auto build)’
Building a simple C++ Project -- "Hello World" on a Windows Platform
- 1. Follow the instructions, on the respective web site, to install your GNU tools.
- 2. Create a new C++ project
- 3. In the C/C++ Projects View, select your new C/C++ project, right click and select "Rebuild Project"
- 4. You will have two additional files. "hello.o" and "hello.exe"
- 5. Double click on "hello.exe" or right click and select "Open With" > "Default Editor" to launch your simple program.
Can I see the raw compiler output? Where is this information placed?
The C-Build view is a console which shows all of the activity which occurs once a project's build command is executed.
I get the error 'Build error (Exec error: Launching failed)'
This usually indicates that "make" is not on your path. Open a command window and type "make". If you receive the equivalent of "command not found" then you will need to ensure that the location of the make executable is on your path. (If you have changed your build command to something else, like "mingw32-make -f makefile" then this something else needs to be on your path.)
Note that the managed build project will always use "make.exe". If make.exe does not exist it will not work.
I get "make Error 127 line 0" when trying to build
Ensure that you have the appropriate GNU tool chain (make, gcc, g++, gdb) installed and available on the path.
My Compiler errors seem to be truncated or split. What is going on?
When using GCC toolchain, you need to add to each compile/link line the following (either in Makefile, add this to CFLAGS/CXXFLAGS/LDFLAGS, or when using managed builds, add this in each configuration to the misc-sections):
-fmessage-length=0
This will disable the line breaks in the compiler and linker error messages.
What causes the message 'make (e=2): The system cannot find the file specified'?
This message usually indicates that the a tool called from inside the makefile is not found (on the path). If the error looks like the following, then "gcc" could not be found:
gcc -c hello.c Process begin: CreateProcess((null), gcc -c hello.c, ...) failed. make (e=2): The system cannot find the file specified.
You will need to ensure that the path to the executable "gcc" is on your path.
You might also want to check that the path delimiter of the PATH environment variable on Windows Systems is a backslash (\), but eclipse need to have the path delimited with forward slashes (/). So you might have to change the appropriate environment variable string.
How do I exclude files from being built in a managed make project? I have tried setting up individual source folder in the Project->Properties panel, but the managed make seems to always include all source file in the project, regardless of the Project Paths settings.
The ManagedBuilder does not respect the src paths when generating the makefile (as of CDT 2.0). However, there is a hack to prevent the generated makefile from building files.
To remove the file "devices/devices.c[pp]" from the build, add a file named "makefile.defs" to the project ROOT and added the following lines to it:
OBJS := $(OBJS:devices/devices.o=)
That has the effect of removing the offending (i.e. non-compiling) sources from the required objects and hence make will never attempt to build them.
Why does CDT with MinGW do full rebuilds on all of my build and launch actions although all settings suggest an incremental build?
For some reason the internal builder forces full rebuilds with MinGW, when the option "Use parallel builds" in Project->Properties->C/C++-Build->Behaviour is used.
Why do I get the an error saying "make: *** No rule to make target `all'."?
From one user on IRC.
- I've found the source of my troubles. MingW needs to be installed to C:\mingw, or CDT does not detect it. My own fault for choosing an option in the installation that's not the default, when I don't yet understand how everything works. The key here is to uncheck "Show project types and toolchains only if they are supported on the system." After that, I can select MingW GCC which I have installed to a different location, and now makefiles are gene
Debugging C/C++ Projects
Can I debug a process that I didn't develop in Eclipse?
Yes, with the Indigo release, CDT supports project-less debugging.
This means that you can choose any binary on your system and ask Eclipse to debug it.
Furthermore, for an attach session (local or remote), there is even no need to specify the binary; for a local attach, GDB can find the binary automatically, while for a remote attach, CDT will prompt for it when it needs it.
I've been asked for 'gdb traces', where can I find them?
A special console output is available when doing debugging to monitor the communication between CDT and GDB. This output can be very useful when troubleshooting a problem with CDT or GDB. You can access this console by going to the Console View and then selecting the little arrow next to the blue TV icon. You will be shown a list of different consoles, where you will see one called 'gdb traces'. Once selected, you can use the Save button of the Console view to quickly save the output to a file.
Those traces can be enabled/disabled, and limited in size using Preferences->C/C++->Debug->GDB. They are enabled by default and should not affect your debugging session.
I don't see the debug preferences pages
Because CDT provides different debugger integration, there are different preferences pages. This had the risk of confusing the user with preferences that may not have any effect on the actual debugger being used. To try to remedy that, debug preferences pages are only shown once a particular debugger integration has been used at least once.
This implies that no debug preferences page will be visible until the very first debug session is started.
How can I inspect the contents of STL containers?
CDT debug now supports full pretty-printing of STL structures using GDB 7.0 or later. This means that complex structures such as Maps, Lists and Vectors, will be shown in a user-friendly fashion. This does require proper setup of GDB as described below.
Without pretty-printing:
With pretty-printing:
Configuring GDB for pretty-printing:
- You will need to have python installed on your machine
- If you want to pretty-print STL structures, you will need the Python pretty-printers for STL. Check-out the latest Python libstdc++ printers to a place on your machine. (Note that you can create your own pretty-printers for any complex-structure). In a local directory, do:
svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
- The following is a workaround for a gdb bug (http://sourceware.org/bugzilla/show_bug.cgi?id=12555) until it is finally fixed there: In the printers.py, locate StdStringPrinter#to_string. Right behind the calculation of len, add the following lines (use whatever limit you feel is appropriate):
if len > 100: len = 100
- You will need to create a gdbinit file to tell GDB where the pretty-printers are. Create a gdbinit file with the following 6 lines. The path needs to match where the python module above was checked-out. So if checked out to: /home/marc/gdb_printers/, the path would be as written in the example:
python import sys sys.path.insert(0, '/home/marc/gdb_printers/python') from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end
- You will need GDB 7.0 or later. That latest version of GDB is recommended because it has bug fixes for the pretty-printing.
- In your CDT launch, make sure it says "Using GDB (DSF) ..."
- In your CDT launch, make sure you use the right GDB and the right gdbinit file. You need to tell eclipse where .gdbinit is located - Window -> preferences -> C/C++ -> Debug -> GDB
How do I do Reverse Debugging?
CDT Debug supports Reverse Debugging. This is a GDB feature that allows you to not only execute your binary forwards, as expected, but also backwards, reverting all memory and registers to their previous values. This feature is only supported by GDB for Linux at the time of writing.
- You will need GDB 7.0 or later for this feature.
- Enabling Reverse Debugging dramatically reduces the performance of execution. A recommended approach is to execute the binary without enabling Reverse debugging until you are close to where the problem happens and only then enable the Reverse debugging feature.
- Reverse debugging works also using gdbserver on a remote target.
Enabling Reverse Debugging
This only needs to be done once for a workspace.
- Go to the "Window" menu and select "Customize perspective..."
- Choose the "Commands group availability tab" and enable "Reverse debugging" as shown below
A single new button will appear, allowing you to enable/disable Reverse debugging. When that button is pressed, GDB will start recording every memory and register change. Once the button is unpressed, all recording will be discarded. Also, when that button is pressed, the other Reverse debugging buttons will appear, allowing you to do:
- Reverse Resume
- Reverse Step-into
- Reverse Step-over
- Reverse Step-return
What is the difference between Non-stop and All-stop multi-threaded debugging?
When using GDB 7.0 or later, CDT allows to choose between Non-stop debugging and All-stop debugging. Non-stop debugging allows each thread of a debug session to be controlled independently. This allows to stop one or more threads while leaving others running. In constrast, All-stop mode interrupts and resumes all threads at the same time.
Non-stop mode is useful when you are not interested in some threads and prefer to leave them running. For example, a heartbeat thread or a watchdog thread may need to keep running while other threads are being inspected.
Choosing between Non-stop and All-stop mode is done per launch in the Debugger subtab. You will require GDB 7.0 or later.
A global preference can be set in Preferences->C/C++->Debug->GDB to default to Non-stop mode for any new launch.
How do I debug a remote application?
With CDT there are three launches to debug a remote application:
- Automatic Remote Launcher
- Manual Remote Launcher
- Remote Attach Launcher
The Manual and Automatic Remote Launchers are meant to be used to start the application on the remote machine in debug mode. The Remote Attach Launcher is meant to debug one or more already running applications on a remote machine.
Automatic Remote Launch
This launch will automatically download your application to the remote machine (unless specifically told not to), will start gdbserver on the remote machine using that application, and will connect GDB to the gdbserver just started. You can also specify some commands to be run before gdbserver is started.
Note that for this launcher to be available, you must have installed the Remote System Explorer End-User Runtime (RSE).
In Debug Configurations... select the C/C++ Remote Application debug configuration type. If RSE is installed, the launch will automatically use the "GDB (DSF) Automatic Remote Debugging Launcher", as can be seen a the bottom of the launch dialog:
This Automatic launch needs extra information in its Main tab and Debugger tab. In the Main tab, you must choose the Connection to the remote machine. A new connection can be created directly from the tab if needed. The remote machine can also point to the host itself if so desired. You must then specify the path on the remote machine where the application should be downloaded (or where it already is); if the application is already on the remote machine, you can select "skip download to target path", however the remote path must still be specified (so we can tell gdbserver where the binary is located).
As for the Debugger tab, it has a new "Gdbserver settings" subtab. In this subtab, you must specify the location of gdbserver on the remote machine. Note that when connecting to the remote machine, the PATH variable may not be set properly, therefore it is safer to use an absolute path for the gdbserver location. In this subtab you also have the option to change the default port that will be used for the connection.
Manual Remote Launch
This launch expects you to manually start gdbserver on the remote machine using the application that you downloaded yourself. Every time your re-launch, you will need to restart gdbserver (as it usually terminates when the debug session terminates). If you don't have RSE installed, you cannot use the "Automatic Remote Launch" and will need to use this one instead.
When using this launch, you should first start gdbserver like this:
remote> <gdbserverPath>/gdbserver :<port> <applicationPath>
for example:
remote> /usr/bin/gdbserver :9999 /home/user/testing/myapp
Then, from Debug configurations... select C/C++ Remote Application debug configuration type. If RSE is not installed, the launch will automatically use the "GDB (DSF) Manual Remote Debugging Launcher", as can be seen a the bottom of the launch dialog:
This Manual Remote launch needs extra information in its Debugger tab where you will see a "Connection" subtab. In this subtab, you must specify the type of connection, the remote machine's address, and the port that will be used for the connection; the port must be the same as the one that was used when launching gdbserver.
Remote Attach Launch
This launch allows you to debug any of the running applications on a remote machine. In fact, you can debug more than one running process at once.
You must have a gdbserver daemon running on the remote machine.
If a gdbserver is not already running on the remote machine, or if all running instance are already connected to, you must start one like this:
remote> <gdbserverPath>/gdbserver --multi :<port>
for example:
remote> /usr/bin/gdbserver --multi :9999
Then, from Debug configurations... select C/C++ Attach to Application debug configuration type. The launch will use the "GDB (DSF) Attach to Process Launcher".
This launch configuration type is used for both local attach and remote attach, and defaults to the local attach case. You must tell it to use gdbserver, to enable to the remote case. This is done in the Debugger tab using the 'Debugger' dropdown box.
This launch needs extra information in its Debugger tab where you will see a "Connection" subtab. In this subtab, you must specify the type of connection, the remote machine's address, and the port that will be used for the connection; the port must be the same as the one that was used when launching gdbserver.
How do I use multi-process debugging?
With the CDT 8.0 (Indigo) release, you can now debug multiple processes in a single debug session. It allows to attach/detach and start/stop processes repeatedly and easily.
Requirements:
- GDB 7.2 or greater
- Currently, only Non-Stop debugging sessions support multiple processes.
- Note that this feature was developed and tested on Linux systems, and may not work on Windows.
To use multi-process debugging, simply launch an application as you normally would, locally or remotely, using gdbserver, and make sure to select Non-stop mode in the Debugger tab. Then, use the Debug View's "Connect" button to trigger a dialog with allows you to either attach to a running process, or to create a new process using the "New..." button. Currently, the "New..." button is only supported for Local debug sessions.
You will then have the newly selected process added to your debug session, where you can control it and examine it. You can use the "Disconnect" button to remove processes from your debug session, or you can use the "Connect" button to add new ones.
An option to automatically attach to a forked process is also available. This means that whenever any process you are currently debugging forks a new process, that new process will be added to your debug session.
How can I trace my application using C/C++ Tracepoints?
In some applications, it is not feasible for the debugger to interrupt the program's execution long enough for the developer to learn anything helpful about its behavior. If the program's correctness depends on its real-time behavior, delays introduced by a debugger might cause the program to change its behavior drastically, or perhaps fail, even when the code itself is correct. It is useful to be able to observe the program's behavior without interrupting it.
Using C/C++ Tracepoints, you can specify locations in the program, called tracepoints, and arbitrary expressions to evaluate when those tracepoints are reached. Later, you can examine the values those expressions had when the program hit the tracepoints. Because tracepoints record these values without interacting with the user, it can be done quickly and unobtrusively, hopefully not disturbing the program's behavior.
Requirements:
- GDB 7.2 or greater
- Only remote debugging sessions support Tracepoints. However, running gdbserver on your host allows you to trace the host.
- Non-Stop debugging is recommended
- Note that this feature was developed and tested on Linux systems, I don't believe it is supported on Windows.
To perform a GDB Tracepoint session, follow the below steps.
Enable the C/C++ Tracepoint functionality
This only needs to be done once for a workspace.
- Go to the "Window" menu and select "Customize perspective..."
- Choose the "Commands group availability tab" and enable "C/C++ Tracepoints" as shown below
Doing this will allow you to choose between creating C/C++ Breakpoints or C/C++ Tracepoints.
Create Tracepoints
Tracepoints are handled as a type of breakpoint. There are two differences to note:
- When a tracepoint is created in a debug session, it is not actually planted in the binary code until the user explicitly starts the tracing experiment. This means that creating/modifying/deleting tracepoints does not affect the program until tracing is actually started.
- Simply creating a Tracepoint has very limited value as it won't collect any information by default. It is important to add Actions to the Tracepoint to tell it what to do. This will be explained below.
The first step in creating Tracepoints is to tell Eclipse that we want to create Tracepoints instead of breakpoints. To do so, right-click on the margin of the editor, and select "Breakpoint types->C/C++ Tracepoints". If you don't see this type of breakpoint available, you probably didn't enable the Tracepoint functionality. See the previous step. You can also access this menu from the main "Run" menu and select Breakpoint types->C/C++ Tracepoints".
Once this is done, double-clicking on the Editor or the Disassembly view margin will set Tracepoints instead of Breakpoints. To set breakpoints again, simply right-click again on the margin of the editor, and select "Breakpoint types->C/C++ Breakpoints".
Note that Tracepoints and Breakpoints can co-exist in the same workspace, and even debug session.
Adding actions to a Tracepoint
Once you have created one or more Tracepoint, they need to be told what to do. Access the Tracepoint properties (actually called "Breakpoint Properties..."). You can do this by right-clicking on the editor margin or through the Breakpoints view.
Tracepoint properties currently contain two pages:
- Actions. Used to tell the Tracepoint what to do, such as collecting data.
- Common. To modify other Tracepoint attributes such as the condition, enablement or passcount.
In the Actions page, you will need to define a set of actions that can be re-used for different Tracepoints. This is mirrored on the handling of CDT Breakpoint Actions.
There are three types of Tracepoints actions supported by GDB:
- Collect. This action will tell the tracepoint to collect data.
- Evaluate. This allows to manipulate trace state variables.
- While-stepping. This allows to perform a set of sub-actions more then once, as GDB steps the program after hitting the tracepoint.
Collect
This command accepts a comma-separated list of any valid expressions. In addition to global, static, or local variables, the following special arguments are supported:
$regs Collect all registers. $args Collect all function arguments. $locals Collect all local variables.
You can give several consecutive collect commands, each one with a single argument, or one collect command with several arguments separated by commas; the effect is the same.
Evaluate
Evaluate the given expressions when the tracepoint is hit. This command accepts a comma-separated list of expressions. The results are discarded, so this is mainly useful for assigning values to trace state variables without adding those values to the trace buffer, as would be the case if the collect action were used.
While-stepping
Perform n single-step instruction traces after the tracepoint, collecting new data after each step. The while-stepping will prompt for a set of sub-commands of what to collect while stepping.
Once you have at least one available Tracepoint action, you can select it and attach it to the current Tracepoint.
Using passcount
The passcount attribute is a way to automatically stop a trace experiment. If a tracepoint's passcount is n, then the trace experiment will be automatically stopped when that particular tracepoint is hit n times. Note that hitting the passcount limit will stop the entire tracing experiment and not simply the enablement of this particular tracepoint. To disable a tracepoint after a certain count, one must use a tracepoint condition and a trace state variable.
Now that your Tracepoints are all setup, it is time to run the application and trace it. Note that creating Tracepoints does not automatically start tracing the application, even if the debug session is running. Instead, once all tracepoints are created, you must manually enable tracing.
Start a remote debugging session using gdbserver
Since GDB currently only supports tracepoints while using a remote session, we have to use such a session. Note that if you want to trace your local host, you can still use a remote session and gdbserver, but have it run on the host.
The simplest way to run a remote debug session is to use the Automatic Remote launch delegate if you have RSE installed. It will start gdbserver automatically for you. If you don't have RSE, haven't installed the remote launcher feature, or simply prefer to do it by hand, use the Manual Remote launch delegate.
It is recommended to use Non-Stop mode.
Open the TraceControl view
The TraceControl view is contributed by CDT and allows you to control the tracing of your application. It provides different buttons to:
- Start/Stop tracing
- Refresh the view. As trace information can change rapidly, the view does not always show the latest information. Pressing the Refresh button will fetch the latest data
- Start/Stop Visualizing data
- Deal with TraceState variables
Start tracing
Once all tracepoints are properly created, press the "Start Tracing" button in the TraceControl view to start tracing your application. Have the application resume execution. As tracepoints are silently hit, data is being collected and the size of the content of the trace buffer can be seen to increase in the TraceControl view.
Stop tracing
Once you feel you have collected enough trace data, press the "Stop Tracing" button in the TraceControl view. The trace data can then be examine directly in your current debug session, or can be saved to a trace file for post-mortem examination, in a manner reminiscent of corefiles.
To optionally save the trace data to a file, use the TraceControl view-menu and select "Save Trace Data"
Examine the data
Once you have stopped your tracing experiment, you can examine the collected data. This can be done in two ways:
- Directly in the debug session used to collect the data. This will put GDB in a mode where it reads the collected data instead of the data of the current running program. This mode will keep your application running.
- Post-mortem from a saved trace file, using a new debug session.
To immediately start looking at collected data, one can simply press the trace selection button (the one pointing down) and it will select the first trace record. Then, using the up/down trace selection buttons, one can navigate the trace records.
The standard debug views (expressions, variables, registers) can be used to display the data that was collected. Note that if a particular variable or expression was not collected, it will show as empty or with an error in the view; this is fine.
Since the debugger is gdb, can I simply access the gdb command line interface (CLI)?
Yes, partially. To access the gdb CLI, select the gdb process node in the Debug view. The gdb command line will then be available in the Console view. Though no prompt is visible, you can enter commands at the bottom line of the Console view. Doing so may desynchronize the IDE and gdb, so be careful when driving the debugger using this interface.
I'm using cygwin and when launching the debugger, it complains that it can't find the source file
You must provide a mapping from /cygdrive/c to c:\ (or whatever your drive letter is).
To do this,
- From the editor error page, select the "Edit Source Lookup Path..." button and select the "Add..." button
- Or, in the eclipse IDE, go to menu Window -> Preferences -> C/C++ -> Debug-> Common Source Lookup Path -> Add.
- From the list of lookup containers, choose Path Mapping and OK. You get a New Mapping in the list.
- Select the mapping and then Edit. In the Modify the path mappings dialog, select Add, and then enter:
- /cygdrive/c as the compilation path and
- c:\ as the local file system path.
- Select OK, OK, OK to finish the dialogs.
- Terminate the debug session and restart; it should find your source files now.
This setting will apply to any debug sessions launched from this workspace.
You can also modify the settings in each individual launch configuration.
I get the message "gdb: unknown target exception 0xc0000135 at 0x7c9766c6"
This cryptic message means "Hey can't found a DLL bro, guess which one!".
GDB uses the PATH environment variable on Windows to load DLLs needed by the target that is debugged. You can change the environment via the Debug Launch Configuration. Unfortunately, there is a bug in gdb 7.0 and 7.1 that prevents gdb from passing the new environment to the target. Therefore, you have to set the PATH environment variable outside of Eclipse (before you start Eclipse!). See the discussion here for further details.
Other Questions
Not yet available, in the meantime see old FAQ.
HOWTO debug applications which require a real terminal
A tip has been posted to the cdt-dev mailinglist recently: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg17396.html.
The idea is to start a new terminal yourself such as xterm:
term -title "debugger terminal" -e /bin/sh -c "tty; sleep 3600" &
You can also reuse an existing terminal. tty will tell you its path.
Then you tell gdb that the application should be connected to that terminal:
echo "tty /dev/pts/X" > /path/to/CDT/project/.gdbinit
where /dev/pts/X is the path which tty has printed previously.
Be careful: The ">" redirection will override your existing .gdbinit!
How can I choose another debugger integration for CDT?
CDT provides different options for debugging. The default one is called DSF-GDB and is automatically selected for you. It uses GDB and provides support for the latest features such as Reverse Debugging, Non-stop multi-threaded debugging, Multi-process debugging, Tracepoints, and more. If for some reason, you wish to use the older GDB integration or you prefer to use EDC you can do the following can go to your launch window, and at the bottom of any of the tabs, you will see a hyperlink "Select other...". This is how you can modify which debugger you will use.
"Standard Create Process Launcher" is the old GDB integration.
What should I do when the debugging session misbehaves?
If your debugging session does not behave as it should, there could be a bug in the debugging software. Assuming you are using the default debugger integration of CDT, we heavily rely on GDB for almost all debugging operations. Therefore, if there is a problem, the first step is to determine if the problem is in CDT or in GDB.
- Behaviors pointing to a CDT problem
- GDB is not launched or killed properly
- Views don't behave as expected
- List of threads or processes is incorrect
- Breakpoints cannot be set
- Behaviors pointing to a GDB problem
- Debug session abruptly terminates (GDB or gdbserver crash)
- Step or Resume operations don't behave as expected
- Breakpoint error messages in gdb console
If the problem is likely to be GDB, it should be confirmed. To do this, one can reproduce the same debug session outside of Eclipse, using GDB command-line.
- Gather the gdb traces on the eclipse session (see this FAQ for information on gdb traces)
- Edit the traces to only keep the commands that are sent from Eclipse to GDB (remove all ^done and ^error lines)
- Optionally remove any commands that are not essential to reproducing the problem
- Start gdb from the command line using the MI flag so that GDB accepts the commands as sent from Eclipse :
gdb -i mi
- Copy/paste each command from gdb traces into the GDB command-line (outside of eclipse) to try to reproduce the problem
- If the problem does happen, then you have confirmed it is highly likely to be a GDB problem. The only other explanation is that the sequence of commands used by Eclipse should not be used like that.
Once you know you are dealing with a GDB problem, you can try to understand it better. You can:
- Try the scenario with the latest version of GDB to see if it has already been fixed.
- If the problem happens in the latest GDB version, you can download the GDB code for HEAD, compile it and try the scenario again. This will show if the problem has been recently fixed in GDB or is still present.
- Search the web for the problem.
- You can debug GDB itself. You can use Eclipse/CDT to do that.
- Post a question to the gdb mailing list. Here are some recommendations to increase your chances of getting a quick answer:
- Make sure you have searched the web first.
- Reduce the source code you use to reproduce the problem to the bare minimum.
- Reduce the GDB session you use to reproduce the problem to the bare minimum.
- Shortly describe your problem
- Specify you have tried with the latest GDB and mention if you have tried with HEAD or not.
- Shortly describe your environment (OS, Architecture, if using an emulator, etc)
- Include the minimal GDB session and source code. This will clearly show your problem and will allow others to reproduce it more easily.
Miscellaneous Troubleshooting
Under construction. In the meantime see old FAQ.
When I attempt to run my application, I get the following error
Entry Point Not Found - The procedure entry point __getreent could not be located in the dynamic link library cygwin1.dll.
Cause: a different cigwin1.dll is picked up from your PATH first. Solution: make sure that only the cygwin1.dll that comes with your active installation of Cygwin is available in the PATH environment variable.
Eclipse console does not show output on Windows
In Eclipse CDT on Windows, standard output of the program being run or debugged is fully buffered, because it is not connected to a Windwos console, but to a pipe. See bug 173732 for more details. Either add fflush calls after every printf or add the following lines in the start of the main function:setvbuf(stdout, NULL, _IONBF, 0); setvbuf(stderr, NULL, _IONBF, 0);
Compilers and other 3rd party tools
Does CDT include a compiler?
CDT does not come with a compiler, so if you do not have one you will need to install one. Follows are options available to you:
- MacOS X: Install the developer tools DVD that came with your computer or with you MacOS X DVD.
- Linux: If not already installed, it should be available on your installation CDs.
- Windows: You have a choice of compilers available:
The web page http://www.thefreecountry.com/compilers/cpp.shtml contains a list of free C and C++ compilers for various platforms and targets.
Working on the CDT
How do I get a more recent build than is on the downloads page?
http://download.eclipse.org/tools/cdt/builds/
These plugin builds can be installed for use in the usual way via Software Updates -> Find and Install... but are packed which the corresponding PDE project files and source code.
Once installed you can import the project and source code into the PDE (Plugin Development Environment) so you can modify rebuild and test using the PDE. The PDE function to do this is accessible from File -> Import... -> Plugin Development -> Plug-ins and Fragments. Alternatively, from the Plugin Development perspective's Package Explorer you can access it via a right-click. In either case if you're new enough to eclipse to be reading and following this you almost certainly want import the CDT plugins as with-source projects (so you can change stuff) but import the eclipse plugins the depend on as binary-only projects.
The self-hosting instructions explain how to do this in the (misleadingly named) section 'Importing binary projects'. The basic recipe is:
- Import the cdt plugin as projects with source code...
- Use the default import source (its the design eclipse you're running right now and Install the CDT build package into).
- Select 'Select from all' and 'Projects with source folders'.
- Next>
- Select the org.eclipse.cdt.* plugins/fragments you want to play with (for first experiments you probably want all of them) and 'Add'.
- Finish.
- Import the remaining plugins as binary-only projects so the run-time eclipse you're going to start from the PDE has all the prerequisite plugins the CDT relies on.
- Use the default import source
- Select 'Select from all' and 'Binary projects'
- Next>
- Select your already imported plugins using the 'Existing Plugin' button.
- Swap these for all the rest using the 'Swap' button.
- Finish.
How do I build CDT from CVS if I want an even more recent build and I want all the pieces and parts?
The short answer:
- Connect to CVS repository: :pserver:anonymous@dev.eclipse.org:2401/cvsroot/tools (Or :pserver:anonymous@proxy.eclipse.org:80/cvsroot/tools from behind corporate firewall)
- Check out: org.eclipse.cdt/all
The long answer:
- Switch to the CVS Perspective: Window > Open Perspective > Others ... and select "CVS Repository Exploring"
- Context menu in "CVS Repositories" View, New > Repository Location
- Location - Host: dev.eclipse.org Repository Path: /cvsroot/tools
- Authentication - User: anonymous (no password required)
- Connection - type: pserver
- Click 'Finish'
- Open up the resulting /cvsroot/tools tree.. find org.eclipse.cdt/all
- On each of the projects under 'all', click context menu > Check Out
The smart answer:
- Download CDT project set
- Import it via menu File > Import > Team > Team Project Set
- Use CVS credentials from the short answer
How do I export it so that it can be used with an external Eclipse installation?
- You can either:
- a) Export the CDT feature via File->Export->Plugin Development->Deployable Features. This will automatically export all the required plugins.
- b) Export all the plugins etc. individually or all at once via File->Export->Plugin Development->Deployable Plugins and Fragments. However, this is more error prone and you're better off doing a).
- c) Use the ANT stuff in org.eclipse.cdt.releng to build CDT the way the nightly build does.
How do I use eclipse to develop eclipse?
The self-hosting instructions explain how to use eclipse to develop eclipse.
- If you want to work with the current version of the eclipse code, you will need to connect to the Eclipse Project CVS repository. To connect to the Eclipse Project CVS repository, open the CVS repositories view (Perspective->Show View->Other...->CVS->CVS Repositories) and create a new CVS repository location (right click->New->CVS Repository Location. Enter the following information into the "Add CVS Repository" dialog.
- Connection type: pserver
- User name: anonymous
- Password: <leave empty>
- Host name: dev.eclipse.org
- Repository path: /cvsroot/tools
NOTE: When you are connected as anonymous you will have read rights to the repository, but you will not be able to commit any code.
How do I modify the code and build the result
Its best to work using the PDE perspective - change any file you want! The PDE perspective is basically an extension of the normal Eclipse Java development perspective so the basic mechanics are the same.
However, the source packaging may be a little erratic here and there (it certainly was in the 4.0.2 packages) and so a little hand tidying up may be necessary before things finally build cleanly.
- If when you build you get hundreds of errors and warnings relating to the use of the assert statement the packaged projects Java Compiler source compatability settings are wrong. You'll need to tweak the corresponding project settings so that at least JDK 1.4 source compatibility is set. In early experiments I found a quick and dirty
- Similarly, a few CDT plug-in projects imported might lack source code (in 4.0.2 some xlc and gdbjtag projects) - which can cause PDE errors. You'll need to delete these and re-import them as binary plugins.
How do I run with my changes?
After successfully building the CDT inside Eclipse, one typically wants to run an instance of Eclipse with the freshly built plugins (perhaps after making some changes to the source code). This is very easy to do in the PDE. Here are the steps:
- 1. Open the "Plug-in Development" perspective (you may have to go to "Others" to find it).
- 2. Select the menu action Run -> Run As... -> Run-time workbench.
- 3. You may also use the drop down on the debug icon, select Run-time workbench
How do I submit a fix for a bug?
While using the Eclipse SDK to develop your plug-in, you found a bug in CDT. You submitted a bug report, but need the fix now. You've debugged the problem, and there is a simple fix. So you figured out how to use eclipse to develop eclipse and have written a fix for the bug you found. Now you want to release the fix to the eclipse community. How do you do this?
First, create a patch. You can create a patch by using the Team patch creation facility.
- 1. Select the project you have patched. It must be connected to the CDT CVS repository.
- 2. Right click->Team->Create Patch...
- 3. The Create Patch wizard will prompt you for a file name. You should name your patch with the bugzilla bug report id.
Now you can attach the patch file to the bugzilla bug report, and add a post to the appropriate component developer mailing list. Be sure to include information about what your patch fixes. The committers for the component will evaluate your patch to see if it fixes the bug and is acceptable. If your patch is accepted, it will be released by the component team into the repository.
See more detailed instructions at CDT Contributing.
How do I distribute my changes to my customers?
Anyway that you see fit! Actually, if anybody has suggestions for this answer, please send them to the cdt-dev mailing list.
How do I generate JavaDocs?
The following steps can be used to create JavaDocs for any CDT project.
- 1. Check out the project (i.e. org.eclipse.cdt.debug.core) from dev.eclipse.org with cvsroot /home/tools
- 2. Ensure that you have JavaDoc installed and configured (go to preferences->Java->Javadoc and set the location for the javadoc command
- 3. Select the project in the package explorer, right-click Export, select Javadoc and follow the wizard instructions. It will generate the Javadoc html in a doc directory for that plugin
The result will be a complete JavaDoc hierarchy of all the public APIs for the selected plugin.
How do I add a CDT extension to my PDE project?
- 1. Make sure that you have the C/C++ Development Tools SDK feature installed (Help > About > Feature Details).
- 2. If not, use the software update feature to install it, or download the appropriate zip file distribution from the CDT update site.
- 3. Open the Plugin.xml file for your PDE project.
- 4. On the "Dependencies" tab, add a dependency on one or more of the CDT plugins in the "Required Plug-ins list", for example org.eclipse.cdt.managedbuilder.core
- 5. On the "Extensions" tab, any extension points supplied by the plugins you specified as required should now be visible in the list.
How do I add an Error Parser (or The project seems to build file, but doesn't parse my error output what can I do?)
CDT 7.0 provides RegexErrorParser. You can set up your own custom expressions in Preferences.
If you need to develop a new error parser for ur BuildTool in your plugin its quite easy. Create an Extension for org.eclipse.cdt.core.ErrorParser
<extension id="NewErrorParser" name="New Error Parser" point="org.eclipse.cdt.core.ErrorParser"> <errorparser class="com.xxx.ErrorParser.NewErrorParser"> </errorparser> </extension>
have a look at the source code for (CDT GNU C/C++ Error Parser) GCCErrorParser.java . Then write a new class NewErrorParser. You could also find a stand-alone error parser in separate package which you can copy to start with. For example, org.eclipse.cdt/xlc/org.eclipse.cdt.errorparsers.xlc contains XlcErrorParser. But use unique ID for your own one.
In CDT 7.0 extension point schema was added where you can use UI to create ErrorParser extension and copy SampleErrorParser example from extension point description.
How do I add a Cross platform debugger?
The ELF parser only recognizes a fixed set of architectures. If it is not recognized as a valid type then it is recognized as "none".
E.g. To create an "AVR" aware debugger, create a plugin with the following extension:
<plugin> <extension point="org.eclipse.cdt.debug.core.CDebugger"> <debugger platform="native" name="AVR GDB Debugger" modes="run,attach" cpu="none,avr" class="org.eclipse.cdt.debug.mi.core.GDBServerDebugger" id="org.eclipse.cdt.debug.mi.core.GDBServerCDebugger"> </debugger> </extension> </plugin>
The "cpu="none,avr"" part is of course the magical stuff...
I am developing a plug-in that requires a parsing a c file and obtaining the information such as method signatures, parameter types etc. How can I do this using the CDT parser?
To use the parser, all you need to do is put cdtparser.jar in your class path and code away. As an example, here is how the CDT Core Model instantiates and uses an IParser to build its model.
IProject currentProject = null; boolean hasCppNature = true; String code = ""; //$NON-NLS-1$ // get the current project if (translationUnit != null && translationUnit.getCProject() != null) { currentProject = translationUnit.getCProject().getProject(); } // check the project's nature if (currentProject != null) { hasCppNature = CoreModel.hasCCNature(currentProject); } // get the code to parse try { code = translationUnit.getBuffer().getContents(); } catch (CModelException e) { } // use quick or structural parse mode ParserMode mode = quickParseMode ? ParserMode.QUICK_PARSE : ParserMode.STRUCTURAL_PARSE; if(quickParseMode) quickParseCallback = ParserFactory.createQuickParseCallback(); else quickParseCallback = ParserFactory.createStructuralParseCallback(); // pick the language ParserLanguage language = hasCppNature ? ParserLanguage.CPP : ParserLanguage.C; // create the parser IParser parser = null; try { IScannerInfo scanInfo = new ScannerInfo(); IScannerInfoProvider provider = CCorePlugin.getDefault().getScannerInfoProvider(currentProject); if (provider != null){ IScannerInfo buildScanInfo = provider.getScannerInformation(currentProject); if (buildScanInfo != null){ scanInfo = new ScannerInfo(buildScanInfo.getDefinedSymbols(), buildScanInfo.getIncludePaths()); } } parser = ParserFactory.createParser( ParserFactory.createScanner( new StringReader( code ), (translationUnit.getUnderlyingResource() != null ? translationUnit.getUnderlyingResource().getLocation().toOSString() : ""), //$NON-NLS-1$ scanInfo, mode, language, quickParseCallback, quickParseMode ? new NullLogService() : ParserUtil.getScannerLogService(), null), quickParseCallback, mode, language, ParserUtil.getParserLogService() ); } catch( ParserFactoryError pfe ) { throw new ParserException( CCorePlugin.getResourceString("CModelBuilder.Parser_Construction_Failure")); //$NON-NLS-1$ } // call parse hasNoErrors = parser.parse(); if( (!hasNoErrors) && throwExceptionOnError ) throw new ParserException(CCorePlugin.getResourceString("CModelBuilder.Parse_Failure")); //$NON-NLS-1$ return quickParseCallback.getCompilationUnit();
Here's a quick description of the ParserFactory interface methods you require:
/** * @param scanner tokenizer to retrieve C/C++ tokens * @param callback the callback that reports results to the client * @param mode the parser mode you wish to use * @param language C or C++ * @param log a log utility to output errors * @return * @throws ParserFactoryError - erroneous input provided */ public static IParser createParser( IScanner scanner, ISourceElementRequestor callback, ParserMode mode, ParserLanguage language, IParserLogService log ) throws ParserFactoryError;
/** * @param input the java.io.Reader that reads the source-code input you want parsed * @param fileName the absolute path of the file you are parsing (necessary for determining location of local inclusions) * @param config represents the include-paths and preprocessor definitions you wish to initialize the scanner with * @param mode the parser mode you wish to use * @param language C or C++ * @param requestor the callback that reports results to the client * @param log a log utility to output errors * @param workingCopies a java.util.List of IWorkingCopy buffers if you wish for include files to use CDT Working Copies rather than saved files * @return * @throws ParserFactoryError - erroneous input provided */ public static IScanner createScanner( Reader input, String fileName, IScannerInfo config, ParserMode mode, ParserLanguage language, ISourceElementRequestor requestor, IParserLogService log, List workingCopies ) throws ParserFactoryError;
For other information you can perhaps attach to the CVS repository @ dev.eclipse.org in order to see the rest of the code. The repository path is /home/tools and you can attach anonymously to get the source.
Missing org.eclipse.cdt.templateengine
if you are reading How to register a project template with CDT, the correct dependencies should be org.eclipse.cdt.core and org.eclipse.cdt.ui, you are probably reading an outdated documentation.
CEnvironmentTab
@see org.eclipse.debug.ui.EnvironmentTab
Because of way the Linux kernel source code is architected and configured, it's a bit subtler than you might think.
What are some areas that are not complete
This is an endless list, but here are a few examples:
- Source code formatting
- Integration with profiler
- Refactoring engine
- Full DOM read/write
In addition to submitting fixes, how else can I contribute to the CDT Project?
One initially thinks of submitting patches and enhancing components as the way to contribute. However, there are many other valuable ways to get involved and help.
- You can contribute to this FAQ. Some of the questions could use better answers or you could add Q&A for a particularly nasty problem you've just solved.
- You can participate in the newsgroups. There are many questions that arise on the newsgroup; you can use your eclipse experience to help others.
- You can report bugs.
- You can develop your own plug-ins and provide feedback based on your experience.
- You can write articles.
- But the most important contribution you can make to the success of CDT (or eclipse) is to build real, useful tool plugins for CDT (or eclipse) that solve real problems for users - either as commercial products or open source projects. Take a look at committing to CDT development to learn more about what's involved in contributing on a deeper level.
- CDT Developer FAQ
- Andras Varga's CDT Developers FAQ - unofficial but actually more solid FAQ.
- CDT Wiki page provides assorted collection of links.