similar to: [LLVMdev] LLVM + Eclipse?

2009/12/16 Talin <viridia at gmail.com>: > So, suppose I wanted to create an Eclipse plugin that could read an LLVM > bitcode file. What would be the best way to bridge between the Java and C++ > worlds? I thought about calling llvm-dis as a subprocess and then parsing > the output, but that seems fragile to me. I'd rather deal with the API level > if possible. Hi Talin,

On 12/16/09 1:41 AM, Renato Golin wrote: > 2009/12/16 Talin<viridia at gmail.com>: > >> So, suppose I wanted to create an Eclipse plugin that could read an LLVM >> bitcode file. What would be the best way to bridge between the Java and C++ >> worlds? I thought about calling llvm-dis as a subprocess and then parsing >> the output, but that seems fragile to

Seems the last use of DIFactory in LLVM/Clang is in: clang/lib/CodeGen/CGDebugInfo.cpp to get the enums llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. Shouldn't this be moved to DIBuilder and remove the dependency completely? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

Here's a suggestion - can we make the "union patch" (the inverse of the patch that removed unions) as a downloadable file so that people who are interested in finishing the work can do so? On Tue, Sep 7, 2010 at 7:55 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> > wrote: > >

On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs

On Tue, Sep 7, 2010 at 1:56 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 6 September 2010 01:05, Talin <viridia at gmail.com> wrote: > > DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, > (...) > > false /* isDefinition */, > (...) > > Hi Talin, > > The only difference from what I'm doing is that I only

I didn't know DIFactory existed until you mentioned it just now. And if folks are adding brand new classes to LLVM, can we not follow the naming conventions in the developer guidelines? On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at systemcall.org>wrote: > Seems the last use of DIFactory in LLVM/Clang is in: > > clang/lib/CodeGen/CGDebugInfo.cpp to get the enums

On 6 September 2010 01:05, Talin <viridia at gmail.com> wrote: > DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, (...) >         false /* isDefinition */, (...) Hi Talin, The only difference from what I'm doing is that I only export debug symbols in definitions, not declarations. I may be doing wrong, though, for multi-file compilation (haven't tested

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

Hi all, Is anyone using any flavour of Unix to develop LLVM? I suppose the Apple guys are using Mac, right? ;) I've seen some docs on the website to set-up Visual Studio but I haven't seen anything related to cross-platform IDEs (such as Eclipse) and how to attach the tests to them. So far I'm not doing any modifications to the LLVM and my project is still too small to become a

Last time I looked at the union stuff, I was trying to decide how to implement TargetData.cpp for unions, and whether or not to copy the way structs handled memory layout. Currently structs have an auxilliary data structure (StructLayout) that is used to cache the overall size of the struct and the offset of each member. In the case of unions, it doesn't need the offsets, since they are always

Hello, Erik > Otherwise, I'd like to know what needs to be done to get unions > back in LLVM. Well, the answer is pretty easy: someone should "fix" them to be supported throughout the whole set of libraries and became a "maintainer". Otherwise the feature being unused will quickly became broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and

2009/9/15 Patrick Simmons <simmon12 at illinois.edu>: > cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" > -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend" > /home/renato/llvm-sources Thanks Patrick, I'll give it a try. At least now I know that it can be done. My previous attempts all ended up in memory

Hi Renato, I've been using LLVM with Eclipse for a while now. The way to do it is to build LLVM with CMake and tell CMake to generate an Eclipse project file, like so: cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DBUILD_SHARED_LIBS=ON -DLLVM_TARGETS_TO_BUILD="X86;PowerPC;CBackend" /home/renato/llvm-sources You'll need to modify

On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Otherwise the feature being unused will quickly became broken. It was already broken for ages... :/ Even if you're not using the backends (or MC), having it in front-end only will only confuse new users that will try to use it and hope it just works (my case, a few months ago). If there is nothing,

Here are some issues that I am unclear about. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at

It was a little over two years ago that I saw Chris give a tech talk on LLVM at Google, and that was when I knew that there was a way that I could actually build the programming language that I'd been thinking about for so long. Well, the compiler is still not done, even though I've been plugging steadily away at it in my free time. However, a lot of progress has been made recently,

2009/9/15 Talin <talin at acm.org>: > For example, here's what the "Iterator" interface looks like: > >   interface Iterator[%T] { >     def next -> T or void; >   } So this would be something like: template <class T> virtual class Iterator { T next(); // or void? }; So the power of having two types of return parameters is that you save function

Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at