debug symbol may lost in llvm-10

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 :slight_smile:

Best regards,
Supermole

my_test.zip (6.45 KB)

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.