similar to: [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable

On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: >> A couple of months ago, I started the process of updating my CMake scripts >> to allow my compiler to be compiled with clang. I quickly ran into a problem >> calling the LLVM libraries, which is that I would get

Cool, I'll check it out - thanks! On Wed, Jun 29, 2011 at 12:07 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: > > On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> > wrote: > >> On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at

On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: > A couple of months ago, I started the process of updating my CMake scripts > to allow my compiler to be compiled with clang. I quickly ran into a problem > calling the LLVM libraries, which is that I would get segfaults when calling > LLVM API functions. I posted about this on both the clang and llvm-dev >

On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: >>> A couple of months ago, I started the process of updating my CMake scripts >>> to allow my compiler to be compiled

So this was working fine for me until a few days ago when I checked out the most recent LLVM - the one with the new type system. Now I am getting the same error that I was getting previously. Is it possible that your fix got unfixed when they merged in the new branch? On Thu, Jun 30, 2011 at 2:21 PM, Talin <viridia at gmail.com> wrote: > Cool, I'll check it out - thanks! > >

On Sat, Jul 23, 2011 at 5:09 PM, Talin <viridia at gmail.com> wrote: > So this was working fine for me until a few days ago when I checked out the > most recent LLVM - the one with the new type system. Now I am getting the > same error that I was getting previously. > Is it possible that your fix got unfixed when they merged in the new branch? I wouldn't be surprised if

On Sat, Jul 23, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sat, Jul 23, 2011 at 5:09 PM, Talin <viridia at gmail.com> wrote: >> So this was working fine for me until a few days ago when I checked out the >> most recent LLVM - the one with the new type system. Now I am getting the >> same error that I was getting previously. >> Is it

I've recently been attempting to use clang to build my llvm-based frontend and I'm having some problems. I finally got everything to compile, but I'm getting a strange segfault in DIBuilder when I try to run. The crash occurs inside DIBuilder::createPointerType(). The fourth parameter to this function is a StringRef, whose default value is an empty string. Since I'm not supplying

Hello, Lately, I have been working on moving Debian & Ubuntu packages to a stage2 build. This means that, instead of shipping llvm-toolchain packages built with gcc, we are rebuilding everything a second time using the newly built clang. Now, when pushed to Debian, it caused some unexpected issues in particular with rust reported here:

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

On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote: > Sorry, I meant DIBuilder. DIBuilder is the new DIFactory. I've been playing with it this week and it's much easier and straightforward to use. I'm still having problems to create arrays, though. As far as I remember (from the 2010 meeting), the idea was to replace and deprecate DIFactory. I'm not saying we

Hi, I am wondering if someone can guide me in adding metadata to IR which already contains some metadata. I am trying to add dbg.declare inst for a local variable I added to a function. I used the DIBuilder to build a DIVariable. When I try to compile llc fails with following message. llc: MCAsmStreamer.cpp:273: virtual void<unnamed>::MCAsmStreamer::EmitLabel(llvm::MCSymbol*): Assertion

Hello all, Summary & Context: ------------------------------- I am starting to write a front-end for some domain specific programming languages. Code generation seems to be working fine. However, I am having trouble generating debug info, to be used by gdb. The problem: -------------------- I generate a foo.ll file, that is later compiled into an executable foo. The foo.ll file I

>>> I am  adding local var to existing IR with debug info. I am not using >>> the Pass infrastructure. >>> >>> void InsertDbg(AllocaInst *i, StringRef varname, Instruction, inserbefore) >>> { >>> >>> DIBuilder di(*module); >>> cu = di.createCU        / * How do I get the MDNode of  already in the >>> IR . Instead of

On Fri, Feb 18, 2011 at 1:52 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote: > > Sorry, I meant DIBuilder. > > DIBuilder is the new DIFactory. I've been playing with it this week > and it's much easier and straightforward to use. I'm still having > problems to create arrays, though.

Hi All, DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs to encode debugging information. We are replacing this interface with new simple interface, DIBuilder. Here is one example that demonstrates differences between two interfaces. To create debug information entries to encode volatile type one would use following call in a language front end,

On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 23, 2011, at 12:03 AM, Talin wrote: > > Just a follow up on this - I am still having problems, I never did figure > out a solution. (I've been running with debug off for the last month so that > I could get work done.) > > Here's what I am seeing: I am definitely calling

On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: > Hi All, > DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs > to encode debugging information. We are replacing this interface with new > simple interface, DIBuilder. > Here is one example that demonstrates differences between two interfaces. To > create debug information

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

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