search for: debugloc

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 code , right ? And also I want the compiler can do some inline optimization to my program. So I have to give this CallInst a DebugLoc......

...t 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 = DebugLoc::get(newLine, newCol, N); Inst->setDebugLoc(Loc); I read the DebugLoc back by using const DebugLoc D = Inst->getDebugLoc(); unsigned Line = D.getLine(); outs() << Line <<"\n"; But I can't set the debug info correctly. How can I chang...

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 destructed the assertion is thrown. Would anyone have an idea what I’m doing wrong that causes this? Best, Christian Sch...

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 PrintStackTraceSignalHandler(...

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 getLine()) from the function where I've called setLine(...) function, it returns the changed line...

...ulprit 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 the instruction via one of it’s Create() routines and then call `setDebugLoc()` to it. I propose the addition of a DebugLoc parameter in the *::Create() instruction constructors. This could be in the form of a pure DebugLoc variable or possibly an `Instruction *InheritLocationFromInst` one Some pros of this idea are: - Easier to create instructions with debug location....

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 the seDebugInfo method for the instruction. Abhirup Ghosh M. Tech Department of Computer Science & Engg. IIT, Bo...

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

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 them, leading to misattribution of some source lines. I can't seem to find the specific pla...

..., 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 attached. Cheers, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pip...

...011, 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 line number information on the merged node since it is > not possible to preserve the information that operation is associated > with multiple lines. > > The current approach seems to be 1). Would you conside...

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 getCol() method is defined as: unsigned getCol()const {        return LineCol >&...

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

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 an <> lookup header)))" Seems that the fi...

...pick up a bogus debug loc from the IP. E.g this is what happens with SCEVExpander::expandCodeFor(). There's no way to fix this bug without changing IRBuilder's behavior. >>>> >>>> # Solutions >>>> >>>> 1. Add a method called SetInsertPointAndDebugLoc() which behaves identically to the current SetInsertPoint(). Change SetInsertPoint() so that it doesn't change the current debug loc. >>>> 2. Add a boolean argument to SetInsertPoint() called UpdateDbgLoc which defaults to false. Only change the current debug loc if UpdateDbgLoc is...

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 the debug location is passed to the constructor of a GC point. Patch attached. I do not know anything about GC support, however labels do not have location info but you may be able to use location of th...

...rne 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 line number information on the merged node since it is >> not possible to preserve the information that operation is associated >> with multiple lines. >> >> The current approach seems to be 1...

...de generation. Here is my question, is there a way to pass information attached to Instruction even further down to stages after code generation? NamedMetadata is a good example but it seems that it cannot be attached to Instruction or MachineInstr if I understand correctly. Is there something like DebugLoc which gets preserved all the way but more general than DebugLoc? Thank you in advance. -Bin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120405/e8463413/attachment.html>

...ase 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 (customers really > > want this). > > Right, that would be nice. This should be synthesizable from the > DebugLoc on the instruction in the asm printer, no need to redundantly > encode it into the comment field. Except the DebugLoc stuff isn't all there yet AFAIK. We've been using the comment mechanism for over a year. I agree we should move to synthesizing it from DebugLoc when it's ready....