[LLVMdev] eclipse and gdb

[reed kotler]

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



_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Mishne, Alon]

I’m using Eclipse with gdb to develop and debug llvm.

 

You need to use the “Eclipse IDE for C/C++ Developers” version for that (also sometimes called “Eclipse CDT” – CDT is the C++ component), though you can also download any other Eclipse version and just install CDT on top of it. As for versions, it’s best to use the most recent version you can find. Should work fine on all Linux distros, though some advanced features require a minimum gdb version.

 

As for creating the Eclipse project, think the simplest approach is to configure as usual, then create a “makefile project” in Eclipse and tell it to use the existing makefiles created under OBJ_ROOT – don’t let Eclipse manage your makefiles.

 

-          Alon

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[Tilmann Scheller]

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

[Reed Kotler]

On 07/16/2013 05:21 AM, Tilmann Scheller wrote:
> 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

[Reed Kotler]

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

[Reed Kotler]

On 07/16/2013 05:21 AM, Tilmann Scheller wrote:

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

[Reed Kotler]

The Eclipse indexer seems to get stuck in the Clang unittests/AST

[Reed Kotler]

On 07/16/2013 06:01 PM, Reed Kotler wrote:
> 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.

[Reed Kotler]

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

[Tilmann Scheller]

Hi Reed,

On Jul 17, 2013, at 3:19 AM, Reed Kotler <rko...@mips.com> wrote:

On 07/16/2013 06:01 PM, Reed Kotler wrote:

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.

Yeah, I vaguely remember having to exclude some clang tests from indexing because they take way too long/way too much memory to index.

Regards,

Tilmann

[Tilmann Scheller]

On Jul 16, 2013, at 11:10 PM, Reed Kotler <rko...@mips.com> wrote:

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

[Tilmann Scheller]

On Jul 17, 2013, at 1:19 PM, Tilmann Scheller <tsch...@apple.com> wrote:

I actually never did a build with Eclipse, only used it for code navigation and debugging :)

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

[Stefan Hepp]

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

On 07/17/2013 10:43 AM, Tilmann Scheller wrote:
> Hi Reed,
>
> On Jul 17, 2013, at 3:19 AM, Reed Kotler <rko...@mips.com

[reed kotler]

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

On 07/17/2013 04:35 AM, Tilmann Scheller wrote:

On Jul 17, 2013, at 1:19 PM, Tilmann Scheller <tsch...@apple.com> wrote:

I actually never did a build with Eclipse, only used it for code navigation and debugging :)

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.

[Kevin Streit]

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]
http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F