[llvm-dev] LLVM IR source line error

[David Blaikie via llvm-dev]

On Tue, May 29, 2018 at 5:25 AM Muhui Jiang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi
>
> I am using LLVM to help me do some code analysis. I wrote a LLVM Function
> Pass to help me to generate some information. I use the code below to get
> the source line information for every instruction.
>
> for (BasicBlock &BB : F){
>     for(Instruction &I: BB){
>     DILocation* Loc =  I.getDebugLoc().get();
>     unsigned Line = Loc->getLine()
>     }
> }
>
> I think the function's first block's first instruction's source line
> should be the beginning of the function.
>

I'm not sure why that would necessarily be true - if there are no
instructions associated with the beginning of the function. (no frame
setup, no allocas, etc)


> Most of the functions inside the binary follow the rules. However, I found
> the file system.h in the coreutils-8.28 has a function like below:
>
> 611 static inline void
> 612 emit_backup_suffix_note (void)
> 613 {
> 614   fputs (_("\
> 615 \n\
>
> 616 The backup suffix is '~', unless set with --suffix or
> SIMPLE_BACKUP_SUFFIX.\n\
> 617 The version control method may be selected via the --backup option or
> through\n\
> 618 the VERSION_CONTROL environment variable.  Here are the values:\n\
> 619 \n\
> 620 "), stdout);
> 621   fputs (_("\
> 622   none, off       never make backups (even if --backup is given)\n\
> 623   numbered, t     make numbered backups\n\
> 624   existing, nil   numbered if numbered backups exist, simple
> otherwise\n\
> 625   simple, never   always make simple backups\n\
> 626 "), stdout);
> 627 }
>
> When analysis this function. The first block's first instruction's source
> line is 614 rather than 612 or 613.
>

The first instruction is the call to gettext (presumably expressed by the _
macro) that is on line 614. Doesn't look like there's any instruction that
could/should be attributed to 612 or 613.

The DISubprogram describing the function should probably have some a
"scopeLine" attribute of 613, which might be what you want.


> Is it a bug or any other meaning resulting in such case. Below is the IR.
> The first IR's source line if 614.
>
>   %call = call i8* @gettext(i8* getelementptr inbounds ([221 x i8], [221 x
> i8]* @.str.42, i32 0    , i32 0)) #12, !dbg !1295
>   %0 = load %struct._IO_FILE*, %struct._IO_FILE** @stdout, align 4, !dbg
> !1295
>   %call1 = call i32 @fputs_unlocked(i8* %call, %struct._IO_FILE* %0), !dbg
> !1295
>   %call2 = call i8* @gettext(i8* getelementptr inbounds ([222 x i8], [222
> x i8]* @.str.43, i32     0, i32 0)) #12, !dbg !1296
>   %1 = load %struct._IO_FILE*, %struct._IO_FILE** @stdout, align 4, !dbg
> !1296
>   %call3 = call i32 @fputs_unlocked(i8* %call2, %struct._IO_FILE* %1),
> !dbg !1296
>   ret void, !dbg !1297
>
> Can anyone help me or give me some suggestions? Many Thanks
>
> Regards
> Muhui
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/045fa80c/attachment.html>