search for: divariables

[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 All,   Can we extract name of variable name from "MDNode" ?   1. Neither temp_MDNode->getName() nor temp_MDNode->getValueName() give me "global_int" which is name of a variable.   2. I tried below ways as well. DIVariable DV(mdnode1); Value *v = mdnode1->getOperand(0);//gives add 0x69   3. I have written below code to reach till variable name.        LLVMIname is

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

Closing this, found below links to get variable name.   http://groups.google.com/group/llvm-dev/browse_thread/thread/1a239f0d24db2b5c   http://markmail.org/message/fj5qg44vyjsdde7k#query:+page:1+mid:5zhmyncisenomcga+state:results           I could do following, to get the required information.                 const CallInst *CI = dyn_cast<CallInst>(Insn);                 int numoperands =

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 =

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,

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

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,

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

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, If I have an instance of DISubprogram, can I get the debug info of local variables of the function, including parameters? I tried to use the getVariables() function defined in DISubprogram, but it seemed to return an empty DIArray node when I ran my pass alone using opt. Do I need to enable any other analysis passes in order to populate the data? My related snippet of code is like the

...alue/declare intrinsics to keep the variable metadata alive and the variables to refer to their scope (lexical blocks (that refer to subprograms) or subprograms). So you'd have to walk all the instructions looking for dbg_declare/value (I forget which, perhaps both) and trace those back to the DIVariables, etc... > > Thanks, > Lu > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- A...

Hi folk, In the Source Level Debugging document, llvm.dbg.declare takes two paramters. "The first argument is the alloca for the variable, cast to a {}*. The second argument is the llvm.dbg.variable containing the description of the variable." The second parameter corresponds to DIVariable, what is the corresponding LLVM class of the first parameter? I want to find which

...metadata alive and >> the variables to refer to their scope (lexical blocks (that refer to >> subprograms) or subprograms). >> >> So you'd have to walk all the instructions looking for dbg_declare/value >> (I forget which, perhaps both) and trace those back to the DIVariables, >> etc... >> >> >>> >>> Thanks, >>> Lu >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http...

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

On Thu, Jul 15, 2010 at 1:19 PM, Arvind Sudarsanam <arvind.sudarsanam at aggiemail.usu.edu> wrote: > Hi Devang, > > Thanks for your reply. You mentioned > " First parameter is the compiler generated temp. and 3rd parameter > provides info about the variable, including its name 'u'." > > I did manage to get this far. But, I am finding it difficult to

...other things.) If a memory-homed variable retains its alloca and the alloca retains its metadata, then it seems like it should be straightforward to produce that memory address as the default location for the variable. And if we're in the habit of looking at metadata on normal instructions for DIVariables instead of having dbg.value instructions, then maybe we don't need dbg.value either. Thanks, --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev Sent: Tuesday, September 05, 2017 1:00 PM To: llvm-dev Subject: [llvm-dev] RFC: Introduce DW_...

----- Original Message ----- > On Sat, Jul 20, 2013 at 9:15 PM, Chris Lattner <clattner at apple.com> > wrote: > > Sorry, just getting caught up on an old thread. I haven't been > > involved in discussions of this. > > > > On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> > > wrote: > >> First, let me try to clarify my

Hi Folks, I ran into this assertion failure while compiling a function with a large number of arguments: https://llvm.org/bugs/show_bug.cgi?id=21609 I have coded up the fix as per David's suggestion (added a new header field for DIVariable to separate out ArgNo & LineNo). The proposed diff is attached to the bug. However, there are around 175 testcases across clang & llvm that need

On Sat, Jul 17, 2010 at 12:00 AM, Neal N. Wang <neal.wang at gmail.com> wrote: > Hi folk, > > In the Source Level Debugging document,  llvm.dbg.declare takes two > paramters.  "The first argument is the alloca for the variable, cast to a > {}*. The second argument is the llvm.dbg.variable containing the description > of the variable."  The second parameter