search for: debuglocs

Hi I want to insert some functions into the llvm bitcode ir files. So I use IRBuilder and CreateCall(). But it how error : inlinable function call in a function with debug info must have a !dbg location. I don't know what DebugLoc should I give the new CallInst to setDebugLoc. I Create this CallInst , so this CallInst doesn't hava so-called "DebugLoc" mapping to the source

Hi All, I want to change debug information of an llvm instruction so that the modified debug info is subsequently passed to executable binary. So if I use "addr2line" utility on the binary, it will return my modified debug information. I've tried to change by using the following code snippet: MDNode *N = Inst->getMetadata("dbg"); DebugLoc Loc =

Hello, A few days ago I upgraded to the LLVM/clang ToT (on Jan 19th or so) and I just encountered this assertion. “Expected to drop a reference” which is defined in llvm/lib/IR/Metadata.cpp line 136. I create DebugLoc objects using DebugLog:get(unsigned line, unsigned Col, MDNode *Scope, MDNode *InlinedAt=nullptr) The DebugLoc objects are wrapped in one of my classes and when instances get

Dear there, I'm trying to call BuildMI in my backend to add a machineinstr. BuildMI(MBB, I, I->getDebugLoc(), TII->get(Vanilla::MOV), Vanilla::R1).addReg(MI->getOperand(1).getReg()); But it gives me an error like this: 0 clang 0x000000010e61a56e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46 1 clang 0x000000010e61c209

Thanks for the help. I thought I'd solved the problem (setting the line number information in the instruction metadata) by inserting my own function for setting line number in llvm/Support/DebugLoc.h. I have added a function setLine(unsigned) in DebugLoc class. The function simply sets the LineCol variable as needed. But there is a problem. Whenever I'm checking the line number(calling

Many DI-related bugs are caused by missing Debug Location in an instruction created in a transformation. Most of the time the fix is trivial once you found where the culprit instruction is created (https://reviews.llvm.org/D50263). Currently, when you create a new Instruction, in order to give it DL you have to either use an IRBuilder that is previously set to the correct DL or “manually” create

Oh! I made a mistake by not using setDebugInfo() function present in the Instruction class. Now it's working fully. So, the solution is:- To set the line number for an instruction - 1. Add a function in DebugLoc class located in llvm/Support/DebugLoc.h. Set the line number there to the private variable called LineCol. 2. Call the added function. And then pass the modified DebugLoc object to

I've been investigating a case with the XCore target (which doesn't use FastISel) where the DWARF line number emitted at -O0 results in the xgdb visiting source lines in an unexpected order. I've tracked down the problem to the handling of DebugLocs in the selection DAG, in the getNode method shown bellow. It first tries to find if a similar node already exists in order to use that one otherwise it creates a new one. The problem of this approach is that it will wrongly use the line number debug info from the first node it will find. I can...

Hi I'm trying to find the specific place where a MachineInstr is generated from an InlineAsm IR instruction's constant input argument because I want to label it with the correct DebugLoc. Currently, the InlineAsm MachineInstr itself has the correct DebugLoc, but all the MOVs to registers that are spawned for any (e.g. integer) constant input arguments do not have DebugLoc associated with

..., Kyriakos Georgiou wrote: > I've been investigating a case with the XCore target (which doesn't use > FastISel) where the DWARF line number emitted at -O0 results in the xgdb > visiting source lines in an unexpected order. I've tracked down the > problem to the handling of DebugLocs in the selection DAG, in the getNode > method shown bellow. > > It first tries to find if a similar node already exists in order to use that one > otherwise it creates a new one. The problem of this approach is that it will > wrongly use the line number debug info from the first...

Hi all, When emitting GC information, it can be very useful to emit the debug location of a GC point, represented as a MCSymbol. Infortunately I haven't found any API (JIT and codegen) where I can get from a MCSymbol to a DebugLoc. Does that interface exist? If not, I plan on committing a small change in the GC code where the debug location is passed to the constructor of a GC point. Patch

On Sep 14, 2011, at 7:37 AM, Richard Osborne wrote: > Is there a view on which of the following approaches is better in > general when two nodes with debug locations are merged because of CSE > (either in the MachineCSE pass or because of the CSEMap in the > SelectionDAG): > > 1) Use the DebugLoc of either of the pair of nodes (chosen arbitrarily). > 2) Throw away the

Hi,   1. Below code gives me end column number of the machine instruction.    How can I get the start column number ?   const MachineInstr *First; ..... //First is assigned. DebugLoc MIDB = First->getDebugLoc(); col_begin  = MIDB.getCol();   2. -----------------   If my C block is     {         int t = 10;      }   This gives me value 20, instead of 9. -----------------   3. In DebugLoc the

...giou wrote: >> I've been investigating a case with the XCore target (which doesn't use >> FastISel) where the DWARF line number emitted at -O0 results in the xgdb >> visiting source lines in an unexpected order. I've tracked down the >> problem to the handling of DebugLocs in the selection DAG, in the getNode >> method shown bellow. >> >> It first tries to find if a similar node already exists in order to use that one >> otherwise it creates a new one. The problem of this approach is that it will >> wrongly use the line number debug info...

Just working on some of the gmlt+fission debug info stuff and I came across a comment that might be relevant to reducing the number of distinct debugloc metadata nodes: "or some sub-optimal metadata that // isn't structurally identical (see: file path/name info from clang, which // includes the directory of the cpp file being built, even when the file name // is absolute (such as

> On Nov 6, 2017, at 2:58 PM, Adrian Prantl <aprantl at apple.com> wrote: > > > >> On Nov 6, 2017, at 2:50 PM, Vedant Kumar <vsk at apple.com> wrote: >> >>> >>> On Nov 6, 2017, at 2:32 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>> On Nov 6, 2017, at 2:19 PM, Vedant Kumar <vsk at

On Sep 12, 2010, at 9:44 AM, nicolas geoffray wrote: > Hi all, > > When emitting GC information, it can be very useful to emit the debug location of a GC point, represented as a MCSymbol. Infortunately I haven't found any API (JIT and codegen) where I can get from a MCSymbol to a DebugLoc. Does that interface exist? If not, I plan on committing a small change in the GC code where

On Sep 14, 2011, at 10:34 AM, Jakob Stoklund Olesen wrote: > > On Sep 14, 2011, at 7:37 AM, Richard Osborne wrote: > >> Is there a view on which of the following approaches is better in >> general when two nodes with debug locations are merged because of CSE >> (either in the MachineCSE pass or because of the CSEMap in the >> SelectionDAG): >> >>

Hi all, Just a quick question about passing information all the way down to machine code level. Metadata provides an excellent vehicle to pass extra ad-hoc information along the compilation pipeline. However, If I understand correctly, it seems that MachineInstr does not support metadata, by which I mean metadata cannot be attached to MachineInstr's by now. Metadata can be bundled with

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > I was attempting to reduce the number of files affected, but if you > > want this change I'll go ahead and do it. > > Makes sense, thanks. Please do it as a separate patch from the other > changes though since it will be large and mechanical. Ok, no problem. > > - Tag instructons with source line information