[llvm-bugs] [Bug 25198] New: Clang's debug info not as accurate as GCC's
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Oct 15 10:45:39 PDT 2015
https://llvm.org/bugs/show_bug.cgi?id=25198
Bug ID: 25198
Summary: Clang's debug info not as accurate as GCC's
Product: new-bugs
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: scott+llvm+bugzilla at pakin.org
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
Created attachment 15084
--> https://llvm.org/bugs/attachment.cgi?id=15084&action=edit
Sample C program for testing debug info
Clang is producing inferior debug info than GCC, at least for the
attached piece of code. Here's what happens when I compile with clang
and debug with gdb:
$ clang --version
clang version 3.7.0 (tags/RELEASE_370/final 246655)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -O3 -g -o bad-debug bad-debug.c
$ gdb --args ./bad-debug 123
GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bad-debug...done.
(gdb) b main
Breakpoint 1 at 0x400590: file bad-debug.c, line 6.
(gdb) r
Starting program: /tmp/bad-debug 123
Breakpoint 1, main (argc=2, argv=0x7fffffffe3f8) at bad-debug.c:6
6 volatile int iters = atoi(argv[1]);
(gdb) n
7 volatile int val = 0;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb) p i
$1 = 0
(gdb) p val
$2 = 0
(gdb) n
10 for (i = 0; i < iters; i++)
(gdb) p i
$3 = 0
(gdb) p val
$4 = 1613956150
(gdb) n
11 val = (val + 19191923) * 282833;
(gdb) p i
$5 = 0
(gdb) p val
$6 = <optimized out>
(gdb)
That is, at each step, variables i and val are some combination of
zero, correct (only for val, not i), or optimized out. The exact same
behavior appears when optimizing with -O2 or -O1; -O0 works as
expected, however.
GCC, on the other hand, is providing more meaningful values for i and
val:
$ gcc --version
gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -O3 -g -o bad-debug bad-debug.c
$ gdb --args ./bad-debug 123
GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bad-debug...done.
(gdb) b main
Breakpoint 1 at 0x4004b0: file bad-debug.c, line 5.
(gdb) r
Starting program: /tmp/bad-debug 123
Breakpoint 1, main (argc=2, argv=0x7fffffffe3f8) at bad-debug.c:5
5 {
(gdb) n
6 volatile int iters = atoi(argv[1]);
(gdb)
7 volatile int val = 0;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb)
10 for (i = 0; i < iters; i++)
(gdb)
11 val = (val + 19191923) * 282833;
(gdb) p i
$1 = 3
(gdb) p val
$2 = 1616115193
(gdb) n
10 for (i = 0; i < iters; i++)
(gdb) p i
$3 = 3
(gdb) p val
$4 = -1915599316
(gdb) n
11 val = (val + 19191923) * 282833;
(gdb) p i
$5 = 4
(gdb) p val
$6 = -1915599316
(gdb)
The inner loops are semantically quite similar:
Clang | GCC
-------------------------------------+-------------------------------------
.LBB0_1: | .L4:
imull $282833, %esi, %eax | movl 8(%rsp), %eax
addl $-729504285, %eax | addl $19191923, %eax
movl %eax, 16(%rsp) | imull $282833, %eax, %eax
incl 12(%rsp) | movl %eax, 8(%rsp)
movl 12(%rsp), %eax | movl 12(%rsp), %eax
cmpl 20(%rsp), %eax | addl $1, %eax
movl 16(%rsp), %esi | movl %eax, 12(%rsp)
jl .LBB0_1 | movl 12(%rsp), %edx
| movl 4(%rsp), %eax
| cmpl %eax, %edx
| jl .L4
This leads me to believe that the debug info is at fault, as opposed
to Clang performing some optimization that makes it impossible to
relate names to variables. I'm no DWARF expert, but I believe GCC's
DWARF information is indicating (correctly) that the variables reside
on the stack, while Clang's DWARF information is indicating that val
maps to %eax and i is a constant 0.
Any chance Clang can be updated to make its output more debuggable?
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151015/1edbeb8a/attachment-0001.html>
More information about the llvm-bugs
mailing list