search for: createcompileunit

I get the filename and directory from DISubprogram from reading llvm.dbg.sp and use that to DIBuiler::.createCompileUnit. This leads to "duplicate symbol" error from llc. >>> You need to call di.createCompileUnit() once for your translation unit in the beginning. You don't need to keep track of CU yourself. DIBuilder will take care of it. After words, you can call di.createBasicType(..) and...

Hi, > You need to call di.createCompileUnit() once for your translation unit in the beginning. You don't need to keep track of CU yourself. DIBuilder will take care of it. After words, you can call di.createBasicType(..) and it will work. Actually it doesn't. But if I call di.createCompileUnit(file, dir, producer, ...) with file or...

...n, inserbefore) >>> { >>> >>> DIBuilder di(*module); >>> cu = di.createCU        / * How do I get the MDNode of  already in the >>> IR . Instead of recreating it, using filename and directory I knew out >>> of band */ >> >> DIBuilder.createCompileUnit() does not return anything. >> >>> file= di.createFile >> >> You don't need CU here. >> >>> >>> type= di.createBasicType   //long >> >> same, you don't need CU here. > > If I don't have a di.createCompileUnit.  di.crea...

...>>>> >>>> DIBuilder di(*module); >>>> cu = di.createCU / * How do I get the MDNode of already in the >>>> IR . Instead of recreating it, using filename and directory I knew out >>>> of band */ >>> >>> DIBuilder.createCompileUnit() does not return anything. >>> >>>> file= di.createFile >>> >>> You don't need CU here. >>> >>>> >>>> type= di.createBasicType //long >>> >>> same, you don't need CU here. >> >> If...

On Mar 29, 2011, at 11:18 AM, Vedavyas Duggirala wrote: > Hi, > >> You need to call di.createCompileUnit() once for your translation unit in the beginning. You don't need to keep track of CU yourself. DIBuilder will take care of it. After words, you can call di.createBasicType(..) and it will work. > > Actually it doesn't. But if I call di.createCompileUnit(file, dir, > producer, ......

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

..._pubtypes section. Why is this in the wrong section?? The question: ========= Does anybody have any idea what it is I am doing wrong? The issue seems to be related to generating the info for a CompileUnit. Currently, I am doing this: dibuilder = new DIBuilder(themodule); dibuilder->createCompileUnit(Lang, StringRef("foo.xx")), /*finename*/ StringRef(".") /*Dir*/, StringRef("XXX") /*Producer*/, false /*isOptimized*/, StringRef("") /*Flags*/, 0 /*RV: Runtime Version?*/...

>>> I get the filename and directory from  DISubprogram from reading >>> llvm.dbg.sp and use >>> that to DIBuiler::.createCompileUnit. This  leads to  "duplicate >>> symbol" error from llc. >> If the llvm::Module already has llvm.dbg.sp then you don't need to use DIBuilder::createCompileUnit(). The point, I am missing is how did you get llvm.dbg.sp in module ? >> >> It seems you already h...

...ubject: Re: [LLVMdev] Accessing metadata & creating DIVariable > > > On Mar 29, 2011, at 4:29 PM, Vedavyas Duggirala wrote: > >>>> I get the filename and directory from DISubprogram from reading >>>> llvm.dbg.sp and use >>>> that to DIBuiler::.createCompileUnit. This leads to "duplicate >>>> symbol" error from llc. >> >>> If the llvm::Module already has llvm.dbg.sp then you don't need to use DIBuilder::createCompileUnit(). The point, I am missing is how did you get llvm.dbg.sp in module ? >>> >>&...

...at your exact revision, the assertion seems to trigger while executing: > > DIType(TempEnumTypes).replaceAllUsesWith(Enums); > > in DIBuilder::finalize(). Can you check if TempEnumTypes is null at this point? If that is the issue (which I’m not sure), then you need to call DIBuilder::createCompileUnit() at some point. > > Fred I had a thought, too: are you using two different `LLVMContext`s? That would cause the `metadata` type to compare unequal.

...!4 = metadata !{metadata !5} !5 = metadata !{i32 786484, ...} ; [ DW_TAG_variable ] Documentation says "List of global variables", but it is built as a "One element list containing the list of global variables". Is there a reason it is built that way? Looking at DIBuilder::createCompileUnit it does indeed build it with an extra indirection. Another thing I find strange is the empty lists, such as "List of enums types" in my example above. They apparently end up being one-element lists containing "i32 0". I would expect that the reference to the empty lists would b...

...uld do it now, just saying Clang should have no > more deps on the old DIFactory to avoid header pollution, since it's > only on one enum... ;) > > cheers, > --renato > A couple of other questions about DIBuilder: 1) I notice that there's no 'isMain' parameter to CreateCompileUnit. How do you specify the main module? 2) There's no means to set TheCU other than creating a new compile unit. This means that you have to generate all of the debug info for your module with a single DIBuilder instance, since there's no way to use a pre-existing compile unit. -- -- Talin...

...it ] [/p roj/mtk04456/hello.cpp] [DW_LANG_C_plus_plus] ------------------------------------------------------------------------------ First problem happen : DICompileUnit doesn't find the last four metadata (i.e. enums types, retained types, subprograms, global variables). But DIBuilder::CreateCompileUnit(...) doesn't need any MDNode* arg. It will find those four metadata in the function. I don't know why it can't point to right reference. So I use MDNode::getOperand(..)->replaceAllUseWith(...) to replace those four metadata with right MDNode. But when I compile my new bitcode to...

I forgot to mention this in my initial email. The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c The date on the commit is: Date: Fri Sep 26 12:34:06 2014 Also: Today I grabbed the ToT llvm/clang/clang-extra-tools and I’m working on getting my code to be compatible with it. I can switch back and forth between the current ToT llvm and the old one. Thanks,

...;l8.cpp"); llvm::StringRef dir("/home/cfiles"); const char* producer = "Group"; llvm::DIFactory DICreator(*theModule); llvm::DICompileUnit diCompUnit = DICreator.CreateCompileUnit (DW_LANG_XXX, filename, dir, llvm::StringRef(producer), true); diCompUnit.dump(); // segmentation fault Is anything wrong with my code? Thank you, Best regards, Nurudeen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...

On Wed, Sep 1, 2010 at 8:31 AM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > >> >> On 01 Sep 2010, at 08:47, Talin wrote: >> >> > Once again, I have no idea what this means or how to go about >> > debugging it. >> > This is my biggest frustration with

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

On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that

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

...;t set break-points or do anything else (what else should I be able to do?). The updated file that describes the test case is at: https://dl.dropboxusercontent.com/u/6229900/dwarf1_new.txt I did have to make a few changes to my code to make it work with the latest llvm. In particular DIBuilder::createCompileUnit required an additional parameter "SplitName". But when I added that parameter and fixed a few other things the results were the same. I think I'm generating the DWARF compile_unit, subprogram, lexical-block, and line-number information correctly but I can't seem to get it to wor...