[Bug c++/17491] New: gdb cannot find line numbers of certain templated methods in the stack frame even with -ggdb compilation

["runipg at broadcom dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17491

            Bug ID: 17491
           Summary: gdb cannot find line numbers of certain templated
                    methods in the stack frame even with -ggdb compilation
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: runipg at broadcom dot com

Created attachment 7834
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7834&action=edit
Main program, simply triggers a core dump via an assertion failure

Description

GDB cannot see line numbers for certain templated methods in the stack frame
even though everything is compiled with the -O0 -ggdb flags (see below). In the
frame below #5 and #6 do not have line numbers where as the rest of them do,
which means that gdb cannot step into those templated methods. This makes gdb
virtually unusable on some of our complex C++ code.

(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x002d5df0 in raise () from /lib/libc.so.6
#2  0x002d7701 in abort () from /lib/libc.so.6
#3  0x002cf26b in __assert_fail () from /lib/libc.so.6
#4  0x08055b68 in gdbTest_First_Test::TestBody (this=0x828c608)
    at gdb_test.cc:19
#5  0x08187bd6 in void
testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test,
void>(testing::Test*, void (testing::Test::*)(), char const*) ()
#6  0x0818371c in void
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
void>(testing::Test*, void (testing::Test::*)(), char const*)
    ()
#7  0x0816d1a8 in testing::Test::Run (this=0x828c608) at ../src/gtest.cc:2151
#8  0x0816d8b9 in testing::TestInfo::Run (this=0x828c288)
    at ../src/gtest.cc:2326
#9  0x0816de75 in testing::TestCase::Run (this=0x828c538)
    at ../src/gtest.cc:2444
#10 0x08173c68 in testing::internal::UnitTestImpl::RunAllTests (
    this=0x828c2f0) at ../src/gtest.cc:4315
#11 0x081888f4 in bool
testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool>(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*) ()
#12 0x0818427c in bool
testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool>(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*) ()
#13 0x08172acd in testing::UnitTest::Run (
    this=0x8272600 <testing::UnitTest::GetInstance()::instance>)
    at ../src/gtest.cc:3929
#14 0x08055d45 in RUN_ALL_TESTS ()
    at /projects/ntsw-arch-public/tools/gtest-1.7.0/include/gtest/gtest.h:2288
#15 0x08055b9d in main (argc=1, argv=0xffffba64) at gdb_test.cc:34
(gdb) up
#6  0x0818371c in void
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
void>(testing::Test*, void (testing::Test::*)(), char const*)
    ()
(gdb) up
#7  0x0816d1a8 in testing::Test::Run (this=0x828c608) at ../src/gtest.cc:2151

How to Reproduce

Unfortunately this has been a really hard bug to reproduce. Here are some
variables which seem to be affecting it:

1. Compile flags for example removing -fPIC from the compile and link seems to
help to some degree but not completely eliminate the problem
2. Moving templated code from exter template cc files to self contained .h
files seems to help, but not completely eliminate the problem
3. Linking to other objects (even though they are not used)

Environment
â    the operating system verson (output of uname -a)
Linux lc-sj1-4507 2.6.18-308.11.1.el5 #1 SMP Fri Jun 15 15:41:53 EDT 2012
x86_64 x86_64 x86_64 GNU/Linux
â    the compiler version (for GCC, the output from gcc -v)
g++ (GCC) 4.7.2
â    how GDB was configured (the This GDB was configured as line from GDB's
startup text)
This GDB was configured as "x86_64-unknown-linux-gnu".

Compile:
/tools/bin/g++ -O0 -ggdb -pthread -m32  -Wall -Wno-unknown-pragmas -Wno-error
-Wno-deprecated  -Wno-unused-variable -Wno-overloaded-virtual -Wno-enum-compare
-Wno-write-strings -m32 -fPIC
-I/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include
-I/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/build/unix-linux/ip
-I/projects/ntsw-arch-public/tools/systemc-2.3.0a/include 
-I/projects/ntsw-arch-public/tools/boost_1_54_0/include
-I/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/ip/include
-I/projects/ntsw-arch-public/tools/gtest-1.7.0/include
-I/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include
-I/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/build/unix-linux/ip
-I/projects/ntsw-arch-public/tools/systemc-2.3.0a/include 
-I/projects/ntsw-arch-public/tools/boost_1_54_0/include
-I/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/ip/include
-I/projects/ntsw-arch-public/tools/gtest-1.7.0/include   -c gdb_test.cc -o
/projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/build/unix-linux/ip/gdb_test.o

I have attached the  simple test program, I use google unit test framework
gtest version 1.7. Note that the bug in this case appears only when I link to a
whole bunch of superflous objects which are not in use by this program. I
cannot attach the executable because of file size limit but can analyze it via
readelf if you wish.

Let me know if you need more information.

-- 
You are receiving this mail because:
You are on the CC list for the bug.