[LLVMdev] Get precise line/column debug info from LLVM IR
Pablo González de Aledo
pablo.aledo at gmail.com
Wed Apr 22 18:39:00 PDT 2015
Hi Eric, thanks for the quick answer. Which version are you using?.
Here we tried it with (both MacOS):
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
clang version 3.5.1 (tags/RELEASE_351/final)
Best regards.
2015-04-23 11:20 GMT+10:00 Eric Christopher <echristo at gmail.com>:
> Try upgrading :)
>
> dzur:~/tmp> ~/builds/build-llvm/Debug+Asserts/bin/clang -g -S -emit-llvm
> -o - foo.c | grep "\!22"
> call void @llvm.dbg.declare(metadata i32* %f, metadata !21, metadata
> !13), !dbg !22
> store i32 %add, i32* %f, align 4, !dbg !22
> !22 = !MDLocation(line: 5, column: 12, scope: !4)
>
> On Wed, Apr 22, 2015 at 6:13 PM Pablo González de Aledo <
> pablo.aledo at gmail.com> wrote:
>
>> I am trying to locate instructions in an LLVM Pass by line and column
>> number (reported by an third-party tool) to instrument them. To achieve
>> this, I am compiling my source files with `clang -g -O0 -emit-llvm` and
>> looking for the information in the metadata using this code:
>>
>> const DebugLoc &location = instruction->getDebugLoc();
>> // location.getLine()
>> // location.getCol()
>>
>> Unfortunately, this information is absolutely imprecise. Consider the
>> following implementation of the Fibonacci function:
>>
>> unsigned fib(unsigned n) {
>> if (n < 2)
>> return n;
>>
>> unsigned f = fib(n - 1) + fib(n - 2);
>> return f;
>> }
>>
>> I would like to locate the single LLVM instruction corresponding to the
>> assignment `unsigned f = ...` in the resulting LLVM IR. I am not interested
>> in all the calculations of the right-hand side. The generated LLVM block
>> including relevant debug metadata is:
>>
>> [...]
>>
>> if.end: ; preds = %entry
>> call void @llvm.dbg.declare(metadata !{i32* %f}, metadata !17),
>> !dbg !18
>> %2 = load i32* %n.addr, align 4, !dbg !19
>> %sub = sub i32 %2, 1, !dbg !19
>> %call = call i32 @fib(i32 %sub), !dbg !19
>> %3 = load i32* %n.addr, align 4, !dbg !20
>> %sub1 = sub i32 %3, 2, !dbg !20
>> %call2 = call i32 @fib(i32 %sub1), !dbg !20
>> %add = add i32 %call, %call2, !dbg !20
>> store i32 %add, i32* %f, align 4, !dbg !20
>> %4 = load i32* %f, align 4, !dbg !21
>> store i32 %4, i32* %retval, !dbg !21
>> br label %return, !dbg !21
>>
>> [...]
>>
>> !17 = metadata !{i32 786688, metadata !4, metadata !"f", metadata !5,
>> i32 5, metadata !8, i32 0, i32 0} ; [ DW_TAG_auto_variable ] [f] [line 5]
>> !18 = metadata !{i32 5, i32 11, metadata !4, null}
>> !19 = metadata !{i32 5, i32 15, metadata !4, null}
>> !20 = metadata !{i32 5, i32 28, metadata !4, null}
>> !21 = metadata !{i32 6, i32 2, metadata !4, null}
>> !22 = metadata !{i32 7, i32 1, metadata !4, null}
>>
>> As you can see, the metadata `!dbg !20` of the `store` instruction points
>> to **line 5 column 28**, which is the call to `fib(n - 2)`. Even worse, the
>> add operation and the subtraction `n - 2` both also point to that function
>> call, identified by `!dbg !20`.
>>
>> Interestingly, the Clang AST emitted by `clang -Xclang -ast-dump
>> -fsyntax-only` has all that information. Thus, I suspect that it is somehow
>> lost during the code generation phase. It seems that during code generation
>> Clang reaches some internal sequence point and associates all following
>> instructions to that position until the next sequence point (e.g. function
>> call) occurs. For completeness, here is the declaration statement in the
>> AST:
>>
>> |-DeclStmt 0x7ffec3869f48 <line:5:2, col:38>
>> | `-VarDecl 0x7ffec382d680 <col:2, col:37> col:11 used f 'unsigned
>> int' cinit
>> | `-BinaryOperator 0x7ffec3869f20 <col:15, col:37> 'unsigned int'
>> '+'
>> | |-CallExpr 0x7ffec382d7e0 <col:15, col:24> 'unsigned int'
>> | | |-ImplicitCastExpr 0x7ffec382d7c8 <col:15> 'unsigned int
>> (*)(unsigned int)' <FunctionToPointerDecay>
>> | | | `-DeclRefExpr 0x7ffec382d6d8 <col:15> 'unsigned int
>> (unsigned int)' Function 0x7ffec382d490 'fib' 'unsigned int (unsigned int)'
>> | | `-BinaryOperator 0x7ffec382d778 <col:19, col:23> 'unsigned
>> int' '-'
>> | | |-ImplicitCastExpr 0x7ffec382d748 <col:19> 'unsigned int'
>> <LValueToRValue>
>> | | | `-DeclRefExpr 0x7ffec382d700 <col:19> 'unsigned int'
>> lvalue ParmVar 0x7ffec382d3d0 'n' 'unsigned int'
>> | | `-ImplicitCastExpr 0x7ffec382d760 <col:23> 'unsigned int'
>> <IntegralCast>
>> | | `-IntegerLiteral 0x7ffec382d728 <col:23> 'int' 1
>> | `-CallExpr 0x7ffec3869ef0 <col:28, col:37> 'unsigned int'
>> | |-ImplicitCastExpr 0x7ffec3869ed8 <col:28> 'unsigned int
>> (*)(unsigned int)' <FunctionToPointerDecay>
>> | | `-DeclRefExpr 0x7ffec3869e10 <col:28> 'unsigned int
>> (unsigned int)' Function 0x7ffec382d490 'fib' 'unsigned int (unsigned int)'
>> | `-BinaryOperator 0x7ffec3869eb0 <col:32, col:36> 'unsigned
>> int' '-'
>> | |-ImplicitCastExpr 0x7ffec3869e80 <col:32> 'unsigned int'
>> <LValueToRValue>
>> | | `-DeclRefExpr 0x7ffec3869e38 <col:32> 'unsigned int'
>> lvalue ParmVar 0x7ffec382d3d0 'n' 'unsigned int'
>> | `-ImplicitCastExpr 0x7ffec3869e98 <col:36> 'unsigned int'
>> <IntegralCast>
>> | `-IntegerLiteral 0x7ffec3869e60 <col:36> 'int' 2
>>
>> Is it either possible to improve the accuracy of the debug metadata, or
>> resolve the corresponding instruction in a different way? Ideally, I would
>> like to leave Clang untouched, i.e. not modify and recompile it.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
--
_ = (
255,
lambda
V ,B,c
:c and Y(V*V+B,B, c
-1)if(abs(V)<6)else
( 2+c-4*abs(V)**-0.4)/i
) ;v, x=1500,1000;C=range(v*x
);import struct;P=struct.pack;M,\
j ='<QIIHHHH',open('M.bmp','wb').write
for X in j('BM'+P(M,v*x*3+26,26,12,v,x,1,24))or C:
i ,Y=_;j(P('BBB',*(lambda T:(T*80+T**9
*i-950*T **99,T*70-880*T**18+701*
T **9 ,T*i**(1-T**45*2)))(sum(
[ Y(0,(A%3/3.+X%v+(X/v+
A/3/3.-x/2)/1j)*2.5
/x -2.7,i)**2 for \
A in C
[:9]])
/9)
) )
-. .----------------------------------------------------
Y
,, ,---,
(_,\/_\_/_\
\.\_/_\_/>
'-' '-'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/fac56a4b/attachment.html>
More information about the llvm-dev
mailing list