I am compiling a program with debugging information, and am attempting to extract !dbg numbers from function calls in LLVM IR. However, I’ve found a few inconsistencies. For example, this call exists in my module:
%1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !“_ZTSFiiE”) #5, !dbg !69, !nosanitize !2
I would like to extract the 69 from this line in my LLVM pass, but when I dump() the corresponding CallInst, I see the following:
%1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !“_ZTSFiiE”) #5, !dbg !29, !nosanitize !2
And finally, the line CallInst → getDebugLoc() → getLine() returns 61 for this call, not 69 or 29.
Am I misunderstanding the purpose of getDebugLoc() for a CallInst? Is there any way I can extract the correct !dbg for a given line? Thanks for your help!
The !69 and !29 refer to metadata (look further down in the LLVM IR dump) that looks something like this:
!10 = !DILocation(line: 3, column: 3, scope: !7)
Which is where the ‘line’ value is stored (so the line is not 69 or 29).
When you extract the function, only the referenced metadata is brought with it, so it gets renumbered - but the semantics remain the same - the line/column/scope is preserved. It’s just there’s fewer metadata nodes, so the metadata node number is smaller.
Broader: Why do you want to know the relative order of calls in IR? That property isn’t especially meaningful - for instance if the calls are in different basic blocks, then it’s /really/ arbitrary, as the order of basic blocks shouldn’t be significant.
Upon re-examining, I think what I really need is the order in which calls take place in the original source code - even if those calls are inlined. I see the DILocation has an InlinedAt field, which seems to be giving me the proper ordering for the code I’m looking at. I’ll play around a bit more with it but I think that should give me what I need. Thanks for your help!