Peter A. Felvegi | 25 Jun 2012 18:15

Regression: incorrect line numbers in debug info since 4.5+

Hello,

I found out while single stepping a new template function in gdb that 
gcc generates bad/inaccurate line numbers in the debug info. 
Optimization was turned off, but the execution jumped strangely, see 
below. gcc-4.4 and the current clang produced the expected results, gcc 
4.5, 4.6, 4.7, 4.8 all had problems. The code was factored out from a 
proof-of-concept hack.

Here is the trace that was produced in gdb by single stepping the 
program with 'n'. The program was compiled w/ gcc 4.8.0 git commit e7ae865c:

COLLECT_GCC=gcc-4.8.0
COLLECT_LTO_WRAPPER=/home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ 
--program-suffix=-4.8.0
Thread model: posix
gcc version 4.8.0 20120605 (experimental) (GCC)

g++-4.8.0 -g -O0 -Wall -Wextra -o dbginfobug.o -c dbginfobug.cpp
g++-4.8.0 -g -o dbginfobug dbginfobug.o

11              while (C c = *f++) {
12                      if (c == '$') {
56                              if (o < e) {
57                                      *o = c;
59                              ++o;
// the first anomaly: the line printed is AFTER the loop, while we're 
still in the loop
(Continue reading)

Ian Lance Taylor | 25 Jun 2012 18:43
Picon
Favicon
Gravatar

Re: Regression: incorrect line numbers in debug info since 4.5+

"Peter A. Felvegi" <petschy <at> praire-chicken.com> writes:

> I found out while single stepping a new template function in gdb that
> gcc generates bad/inaccurate line numbers in the debug
> info.

Thanks for reporting this.  In the future, please send messages like
this to gcc-help <at> gcc.gnu.org, not gcc <at> gcc.gnu.org.  Thanks.

> I couldn't find anything similar in bz, please let me know whether
> this is a new issue and I will file a bugreport.

Please do open a bug report following the instructions at
http://gcc.gnu.org/bugs/  .  Thanks.

Ian

Peter A. Felvegi | 25 Jun 2012 22:14

Re: Regression: incorrect line numbers in debug info since 4.5+

The bug is at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770

Regards, Peter

Jonathan Wakely | 25 Jun 2012 18:44
Picon

Re: Regression: incorrect line numbers in debug info since 4.5+

On 25 June 2012 17:15, Peter A. Felvegi wrote:
> Hello,
>
> I found out while single stepping a new template function in gdb that gcc
> generates bad/inaccurate line numbers in the debug info. Optimization was
> turned off, but the execution jumped strangely, see below. gcc-4.4 and the
> current clang produced the expected results, gcc 4.5, 4.6, 4.7, 4.8 all had
> problems. The code was factored out from a proof-of-concept hack.

Which version of GDB?

As documented at http://gcc.gnu.org/gcc-4.5/changes.html

GCC now generates unwind info also for epilogues. DWARF debuginfo
generated by GCC now uses more features of DWARF3 than before, and
also some DWARF4 features. GDB older than 7.0 is not able to handle
either of these, so to debug GCC 4.5 generated binaries or libraries
GDB 7.0 or later is needed. You can disable use of DWARF4 features
with the -gdwarf-3 -gstrict-dwarf options, or use -gdwarf-2
-gstrict-dwarf to restrict GCC to just DWARF2, but epilogue unwind
info is emitted unconditionally whenever unwind info is emitted.

Peter A. Felvegi | 25 Jun 2012 20:13

Re: Regression: incorrect line numbers in debug info since 4.5+

Hello,
> Which version of GDB?
>
> As documented at http://gcc.gnu.org/gcc-4.5/changes.html
>
> GCC now generates unwind info also for epilogues. DWARF debuginfo
> generated by GCC now uses more features of DWARF3 than before, and
> also some DWARF4 features. GDB older than 7.0 is not able to handle
> either of these, so to debug GCC 4.5 generated binaries or libraries
> GDB 7.0 or later is needed. You can disable use of DWARF4 features
> with the -gdwarf-3 -gstrict-dwarf options, or use -gdwarf-2
> -gstrict-dwarf to restrict GCC to just DWARF2, but epilogue unwind
> info is emitted unconditionally whenever unwind info is emitted.
I was using 7.4.1, under Debian Wheezy, amd64. Tried the dwarf 2 
options, but then I wasn't even able to step into the template function 
from foo(): when hitting step on the function name, the next line was 
the fn closing brace, in asm it jumped from preparing the reg args to 
the leaveq after the call. When stepped inside the fn via si, the first 
'next' attempt failed gdb saying that the fn contained no line number 
info, and stopped at the outer leaveq as before.

With dwarf-3 and 4, the already reported buggy behaviour occured when 
single stepping the function.

Regards, Peter


Gmane