similar to: [LLVMdev] eclipse and gdb

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

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

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

On Jul 17, 2013, at 1:19 PM, Tilmann Scheller <tscheller at 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

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. >>> Hope this helps :) >>> >>> Regards, >>> >>> Tilmann

On Jul 16, 2013, at 11:10 PM, Reed Kotler <rkotler at 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

Tilmann Scheller <tilmann.scheller at googlemail.com> writes: [snip] > It might be worth to put an Eclipse CDT project file with relative > paths to the header files in the LLVM SVN repository to make it easier > for people to use Eclipse in the future (my project files currently > contain absolute paths, so they're probably not useful to other > people). CMake can

Hi Reed, On Jul 17, 2013, at 3:19 AM, Reed Kotler <rkotler at 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

The Eclipse indexer seems to get stuck in the Clang unittests/AST >> 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

Has anyone tried using the Eclipse CDT plugin (or another C++ IDE) to develop code in LLVM? I'm specifically interested in getting code completion to work. --Patrick

Hi Oscar, On Thu, Jul 2, 2009 at 2:59 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> It might be worth to put an Eclipse CDT project file with relative >> paths to the header files in the LLVM SVN repository to make it easier >> for people to use Eclipse in the future (my project files currently >> contain absolute paths, so they're probably not useful to other

Hi Patrick, On Thu, Jul 2, 2009 at 12:17 AM, Patrick Alexander Simmons<simmon12 at cs.uiuc.edu> wrote: > Has anyone tried using the Eclipse CDT plugin (or another C++ IDE) to > develop code in LLVM? I'm specifically interested in getting code > completion to work. I've been sucessfully using the Eclipse CDT with LLVM for quite a while now. The official releases of Eclipse

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

What was the first target for LLVM? Tia. Reed

Hi Reed, I think it was SPARC, feel free to correct me though :) Regards, Tilmann On Apr 15, 2013, at 11:21 AM, reed kotler <rkotler at mips.com> wrote: > What was the first target for LLVM? > > Tia. > > Reed > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >

Tilmann Scheller <tilmann.scheller at googlemail.com> writes: > Apparently CMake deletes the C++ files which are generated by > TableGen, is it possible to tell CMake to not throw them away? Certainly the build does not delete those files. Maybe you looked at the wrong place. Try $OBJDIR/lib/Target/X86, for instance. There you will see the *.inc files that TableGen creates. >

Hi Viktor, On Tue, Apr 5, 2011 at 9:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Jim Grosbach <grosbach at apple.com> writes: > > >> To me, increasing coverage of the FastISel seemed more involved than > >> directly emitting opcodes to memory, with a lesser outlook on > >> reducing overhead. > > > > That seems extremely unlikely.

Greetings, is this the right place to discuss getting LLVM built using Eclipse, as described on http://llvm.org/docs/GettingStarted.html? Regards, Jo

Am 10.10.2015 um 21:14 schrieb Tim Northover: > On 10 October 2015 at 04:16, Joachim Durchholz via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> is this the right place to discuss getting LLVM built using Eclipse, >> as described on http://llvm.org/docs/GettingStarted.html? > > It's probably as good as anywhere, Okay. > but I don't think

Jim Grosbach <grosbach at apple.com> writes: >> To me, increasing coverage of the FastISel seemed more involved than >> directly emitting opcodes to memory, with a lesser outlook on >> reducing overhead. > > That seems extremely unlikely. You'd be effectively re-implementing > both fast-isel and the MC binary emitter layers, and it sounds like a > new