similar to: [LLVMdev] Debug info compileunit metadata strangeness..

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 Mar 29, 2011, at 8:23 AM, Vedavyas Duggirala wrote: >>>> 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 =

I'm trying to write a llvm pass to add debug info into a non-debug-info bitcode file. I have been read http://llvm.org/docs/SourceLevelDebugging.html. And I use DIBuilder to produce the debug metadata. I know I can't get all information form ir code . So I add some manual info as test data. After executing my pass, I can find debug info metadata in my generated bitcode. Those metadata

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

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

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 dir different from that of CU already in the file,

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,

However, I do have: !924 = metadata !{i32 786484, i32 0, null, metadata !"r", metadata !"r", metadata !"", metadata !841, i32 19, metadata !56, i32 0, i32 1, i32* @r} ; [ DW_TAG_variable ] [r] [line 19] [def] with on which `!0` is indirectly dependent and there is `!llvm.dbg.cu = !{!0}` . On Wed, Feb 27, 2013 at 11:35 AM, Alexandru Ionut Diaconescu <

>From a thread with Adrian on llvm-commits I looked a little at cases where DwarfCompileUnit's getOrCreateContextDIE's "fallback to return the CU" didn't fire when a CU DIE was required (ie: when the "getDIE" call actually found the CU before the fallback happened) This seems unnecessary, and any case where we do this (where a metadata node has a non-null

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

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

[Forgot to cc list.] Begin forwarded message: > From: Devang Patel <dpatel at apple.com> > Date: March 29, 2011 4:41:30 PM PDT > To: Vedavyas Duggirala <vduggira at gmail.com> > Subject: Re: [LLVMdev] Accessing metadata & creating DIVariable > > > On Mar 29, 2011, at 4:29 PM, Vedavyas Duggirala wrote: > >>>> I get the filename and directory

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid

I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24). I recompiled debug versions of llvm, clang and my code. I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?). The updated file that

Josh Matthews wrote: >> From DwarfDebug.cpp: > >> /// GetOrCreateSourceID - Look up the source id with the given directory and >> /// source file names. If none currently exists, create a new id and insert it >> /// in the SourceIds map. This can update DirectoryNames and SourceFileNames >> /// maps as well. >> unsigned

Hi, I would like to implement a fix to how LLVM handles/creates debug info for entities declared inside a basic block. Below you will find 5 parts: 1. Motivation for this fix. 2. Background explaining the cases that need to be fixed. 3. An example for each case. 4. Proposal on how to represent each case in dwarf. 5. Secondary (workaround) proposal which might be

On Mon, Dec 14, 2015 at 7:01 AM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I verified that GDB 7.10 does support “DW_AT_abstract_origin” attribute on > “DW_TAG_lexical_block”. > I take it you mean that it does the right thing, finding the direct children of the abstract block when stepping into the inlined subroutine, etc? & this was a

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the