Is anyone using Eclipse and gdb to debug llvm/clang?
If so, which version of Eclipse, gdb and linux flavor.
I just use gdb currently.
I'm going to try using my mac also.
Is anyone using xcode/lldb to debug llvm/clang?
Tia.
Reed
Hi Reed,
I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years).
Xcode works fine as well, I started to use Xcode exclusively when I switched to OS X.
The key to make this work is to use CMake to generate project files for Eclipse/Xcode, you can do this by specifying the appropriate generator on the command line e.g. -G Xcode or -G "Eclipse CDT4 - Unix Makefiles”. Then you can just open the generated project file. Mind you, the generated projects are kind of ugly e.g. the Xcode project has like more than 200 targets but apart from that they are working fine.
In terms of key bindings both Eclipse and Xcode ship with Emacs key bindings and there are plugins which allow you to use vim key bindings as well. With Eclipse I’ve been using the Viable plugin for that and for Xcode there is Xvim.
Hope this helps 
Regards,
Tilmann
Hi Reed,
I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years).
Xcode works fine as well, I started to use Xcode exclusively when I switched to OS X.
The key to make this work is to use CMake to generate project files for Eclipse/Xcode, you can do this by specifying the appropriate generator on the command line e.g. -G Xcode or -G "Eclipse CDT4 - Unix Makefiles”. Then you can just open the generated project file. Mind you, the generated projects are kind of ugly e.g. the Xcode project has like more than 200 targets but apart from that they are working fine.
In terms of key bindings both Eclipse and Xcode ship with Emacs key bindings and there are plugins which allow you to use vim key bindings as well. With Eclipse I’ve been using the Viable plugin for that and for Xcode there is Xvim.
Hope this helps
Regards,
Tilmann
The source browsing is way better this way.
This following pointer may be useful to others to complete the importing of the project.
http://www.vtk.org/Wiki/Eclipse_CDT4_Generator
How are you setting up the debugger?
For example, if you want to run from clang but debug the back end code generation ?
Which process launcher?
Protocol == mi?
BTW: do you do builds inside of eclipse.
Seems to be kind of slow.
Tia.
Reed
I made wiki pages on this.
https://dmz-portal.mips.com/wiki/Building_with_Cmake_to_create_an_Eclipse_Project
https://dmz-portal.mips.com/wiki/Importing_the_Project_into_Eclipse
Hi Reed,
I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years).
Xcode works fine as well, I started to use Xcode exclusively when I switched to OS X.
The key to make this work is to use CMake to generate project files for Eclipse/Xcode, you can do this by specifying the appropriate generator on the command line e.g. -G Xcode or -G "Eclipse CDT4 - Unix Makefiles”. Then you can just open the generated project file. Mind you, the generated projects are kind of ugly e.g. the Xcode project has like more than 200 targets but apart from that they are working fine.
In terms of key bindings both Eclipse and Xcode ship with Emacs key bindings and there are plugins which allow you to use vim key bindings as well. With Eclipse I’ve been using the Viable plugin for that and for Xcode there is Xvim.
Hope this helps
Regards,
Tilmann
Have you had trouble with the C++ indexer getting stuck in some kind of infinite loop indexing.
It's happening to me with this Cmake (but happened too without cmake).
Seems to be a common problem.
I have a giant mac at home and am thinking of maybe switching to mac at work to get a reasonable IDE that is reliable.
The Eclipse indexer seems to get stuck in the Clang unittests/AST
The Eclipse indexer seems to get stuck in the Clang unittests/AST
In Eclipse you can tell it that a given directory is derived, and then it won't try and index it.
Probably the more complex clang tests are too involved for the indexer.
The last step here was to download the eclipse for c++ directly from eclipse and not get the packages from ubuntu, which is what i'm developing on.
For many other things, if it is not coming from Ubuntu directly, there is something that in the end won't work, but it seems that the latest Eclipse works fine; Kepler 4.3 (but you need to download the C++ part too).
Hi Reed,
The source browsing is way better this way.
Definitely! Once I used this for the first time I never wanted to go back to grep for source navigation, it’s so much faster
How are you setting up the debugger?
For example, if you want to run from clang but debug the back end code generation ?
I just create a new launch configuration specifying the binary/working directory/command line arguments and run it in debug mode.
BTW: do you do builds inside of eclipse.
Seems to be kind of slow.
I actually never did a build with Eclipse, only used it for code navigation and debugging
I do builds with Xcode from time to time when I want to debug from within Xcode (when I’m not using LLDB on the command line) because I haven’t figured out yet how to use Xcode to debug a binary which was built outside of Xcode.
The experience is not that great either though, especially incremental building seems to be kind of broken. E.g. before launching the binary in the debugger it will always build the project first to make sure it’s up to date, so in theory if you run your binary twice and didn’t make any changes to the source code after the first run, then in the second run, you should only have an added overhead of determining that nothing has changed.
However, in practice a significant amount of time is spent on just determining that nothing has changed and it also looks like stuff gets rebuilt even though there’s is no need to. I haven’t spent any time to track down what’s actually the problem there but I assume it has to do with the way CMake generates Xcode projects. It’s possible to start debugging without building though so it’s rather easy to workaround
Regards,
Tilmann
Actually that’s not really true, I did build with Eclipse from time to time to get all the sources TableGen generates automatically. This is really nice because the source navigation works just fine across handwritten and automatically generated files.
What I meant to say is that I have two build directories, one for Eclipse/Xcode to have a project file for source navigation and one for my regular build on the console which I use for all the actual development work.
Regards,
Tilmann
Hi,
I am using Eclipse to edit the files, and I used it to debug with gdb as well (but I went back to gdb on the command line, Eclipse GDB UI is just too slow and buggy for me ..).
You need to exclude the clang preprocessor/.. stress tests from the sources, otherwise the indexer will freeze Eclipse. You should also remove some autogenerated CMake project subdirectories, otherwise your files will be opened multiple times when navigating the sources, which *will* cause you to loose/overwrite changes when you save.
Be aware that building the project will rerun CMake if you make any changes to the CMake files, which will regenerate your Eclipse project files, i.e., your Resource Exclusion settings will be lost, i.e., the indexer will get stuck the next time again. You could maybe save the project files to a different directory, I personally just disabled building the project in Eclipse (I use a build directory separate from the Eclipse cmake build dir).
Here is basically how I set up my Eclipse project:
- Use File->Import->General->Import Existing Project. Do not check Copy Sources.
- Setup Resource->Resource Filters in Project settings on project root,
- Exclude */clang/test and */clang/INPUTS project relative paths (recursive)
- Do not use 'Location', causes nullpointer exception on file save
Make sure Indexer does not run before you create the filters!
- Delete the [Targets] and [Subprojects] directories (or whatever
they are called)
- Setup project settings:
- Setup coding style to new derivative from GNU, edit line-breaks settings
- Setup Project Include-path settings: add following paths and defines:
- /usr/include
- /usr/include/c++/4.6
- /usr/include/c++/4.6/x86_64-linux-gnu
- /usr/include/x86_64-linux-gnu
- GET_REGINFO_MC_DESC, GET_REGINFO_HEADER,
GET_REGINFO_TARGET_DESC, GET_ASSEMBLER_HEADER,
GET_MATCHER_IMPLEMENTATION
- Setup Texteditor Font to Deja Sans Mono or any other font that
has same character width for normal and bold text!
- Setup dictionary for 'C++ Spell Checker'
General spell checker dictionary does not remember words.
For debugging, you might want to consider the 'GDB (DSF)' launcher, which supports pretty printing. However, I found this way of running GDB a bit unstable (You may need to restart Eclipse if your Variable view stays empty during debugging), and back then I had some problems when compiling LLVM/clang as shared libraries.
I made some initial efforts to create GDB pretty printing python scripts similar to STL pretty printing for the LLVM containers. It is far from complete, but it has initial support for some of the most common containers. I had some problems with pretty printing for STL in the past when I compiled LLVM with clang, but I think it works now with the latest clang/LLVM/gdb versions.
You can find my code for pretty printing for GDB for LLVM together with some infos on how to setup Eclipse for debugging here, if you want to give it a go:
https://github.com/t-crest/patmos-llvm/tree/master/utils/gdb
Basically, you need to check out the 'python' folder somewhere, check out the 'gdbinit' file, modify the paths to your system and make your gdb load the gdbinit file (beware, the Eclipse Standard Process launcher and the GDB (DSF) launcher seem to behave differently regarding whether they load the ~/.gdbinit file by default or not).
Cheers,
Stefan
The latest release of Eclipse (which is Kepler) did not have any indexing problems.
There were bugs in the older ones where the indexer went into an infinite loop
sometimes.
If you have a build with cmake, you can just type make at the command line there too.
It seems that command line "make" within cmake areas is much faster than when building in an area using the traditional "configure".
Hi,
From time to time I am using eclipse as well to work on llvm.
CDT and in particular the indexer are quite demanding when it comes to memory
consumption and I experienced that the default maximum heap size is not enough for that
and will eventually lead to freezes or similar.
After increasing the maximum heap size in the eclipse.ini [1] (comes with your eclipse
distribution; in Mac it is contained in the Application bundle: Eclipse.app/Contents/MacOS),
say to 3G, I experienced no problems and did not have to exclude any files from indexing.
Cheers,
Kevin
[1] FAQ How do I increase the heap size available to Eclipse? - Eclipsepedia