In relationship with optimisation (inlining)
the source file / line number information in
the debugging sections are wrong. This is a
major problem when debugging code (being
given a wrong source file, it is impossible
to know where the location really is/was).
any (i686-gnu-linux here)
See follow up: it is absolutely impossible
to paste things in this web interface using
From: Carlo Wood <email@example.com>
Subject: Re: debug/5271: Wrong line number information.
Date: Fri, 4 Jan 2002 05:03:20 +0100
Call the following preprocessed file "bug.ii"
# 14 "libcwd.tst/leak.cc"
# 206 "../include/libcw/macro_AllocTag.h"
i += 1234;
# 19 "libcwd.tst/leak.cc"
int t = foo(*new int);
Next compile this file with a command like:
~/c++/libcw/src/libcwd/testsuite>/usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cc1plus -fpreprocessed bug.ii -quiet -dumpbase leak.cc -gdwarf-2 -O -version -o bug.s
GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.0.3.
This will result in a file bug.s that shows that
the line number information is such that the call
to 'new int' appears to be made in macro_AllocTag.h
while obviously it is done in main() in leak.cc.
.file 2 "libcwd.tst/leak.cc"
.loc 2 21 0
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
.loc 2 22 0
.file 3 "../include/libcw/macro_AllocTag.h"
.loc 3 209 0
subl $12, %esp
addl $16, %esp
.loc 3 210 0
movl (%eax), %eax
addl $1234, %eax
.loc 2 23 0
.loc 2 24 0
movl %ebp, %esp
Clearly, the line ".loc 3 209 0" should not be there.
Carlo Wood <firstname.lastname@example.org>
State-Changed-Why: Confirmed, problem still exists in present mainline of
today. The call to operator new happens before we jump into
foo, but this is not reflected in the debug info. Needless
to say that the problem goes away once we switch off
This is a dup of bug 4431 which is related to bug 10003.
*** This bug has been marked as a duplicate of 4431 ***
Not a duplicate of 4431.
*** Bug 4431 has been marked as a duplicate of this bug. ***
For the mainline and 4.0.0, the issue is really PR 19192.
Fixed in 4.0.0.