[llvm-dev] debug symbol may lost in llvm-10
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Mon Aug 17 14:06:35 PDT 2020
On Sat, Aug 15, 2020 at 10:05 AM zy j via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev