Hi, I compiled my toy program with following command: `clang -c -fno-discard-value-names -g -O0 -emit-llvm my_test.c -o my_test.bc`, however, some debug symbols will lost after this compiling. I have attached my showcase in this email. For example, the debug symbol of line 7 in my_test.c will lost after compiling, user can't get the variable name, which should be `buf` in fact. I tried to parse the llvm IR by using SVF(https://github.com/SVF-tools/SVF) and noticed this problem, and I have asked the developer of SVF, who suggest me to ask the llvm developer( https://github.com/SVF-tools/SVF/issues/297) waiting for your reply :) Best regards, Supermole -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200815/3d210334/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: my_test.zip Type: application/zip Size: 6600 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200815/3d210334/attachment.zip>
David Blaikie via llvm-dev
2020-Aug-17 21:06 UTC
[llvm-dev] debug symbol may lost in llvm-10
On Sat, Aug 15, 2020 at 10:05 AM zy j via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi, > > I compiled my toy program with following command: `clang -c -fno-discard-value-names -g -O0 -emit-llvm my_test.c -o my_test.bc`, however, some debug symbols will lost after this compiling. I have attached my showcase in this email. > > For example, the debug symbol of line 7 in my_test.c will lost after compiling, user can't get the variable name, which should be `buf` in fact.When you say "the debug symbol of line 7 ... is lost after compiling" - what do you mean? What specific results did you observe? The bitcode file looks like it has a debug source location for line 7: %call2 = call i8* @strcat(i8* %3, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0)), !dbg !30 ... !30 = !DILocation(line: 7, column: 9, scope: !29) That you're using "-fno-discard-value-names" seems suspicious to me - those names, even with "no-discard" aren't going to be super meaningful. In this case, the variable "buf" is stored in the "buf.addr" alloca, and loaded from it into %3. So if you're looking at value names, you won't find "buf" where you're expecting to, by the looks of it. The debug info itself does describe this correctly here: call void @llvm.dbg.declare(metadata i8** %buf.addr, metadata !13, metadata !DIExpression()), !dbg !14 Saying that value of the variable !13 ("buf") can be found by following the buf.addr pointer.> > I tried to parse the llvm IR by using SVF(https://github.com/SVF-tools/SVF) and noticed this problem, and I have asked the developer of SVF, who suggest me to ask the llvm developer(https://github.com/SVF-tools/SVF/issues/297) > > waiting for your reply :) > > Best regards, > Supermole > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev