bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gdb cannot find line numbers of certain weak symbols during backtrace


From: Runip Gopisetty
Subject: gdb cannot find line numbers of certain weak symbols during backtrace
Date: Mon, 13 Oct 2014 18:59:01 +0000

Category

GDB.

 

Synopsis

        gdb cannot find line numbers of certain weak symbols during backtrace

 

Confidential

No

 

Severity

Serious

 

Priority

Medium

 

Submitter-Id

net.

 

Release

% gdb

GNU gdb (GDB) 7.7

 

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".

How-To-Repeat

 

          Unfortunately I don’t have a simple testcase to repeat. I will work on it in the background, to see if I can reproduce it.  

 

Here are the compile flags I used:

 

g++ -O0 -ggdb -pthread -m32  -fPIC -Wall -Wno-unknown-pragmas -Wno-error -Wno-deprecated  -Wno-unused-variable -Wno-overloaded-virtual -Wno-enum-compare -Wno-write-strings -fpermissive -Wno-div-by-zero …

 

I have also tried –fno-inline and it made no difference.

 

Description

 

The problem is that gdb does not print line numbers for only couple items in the stack frame even though everything was built using the “-ggdb” switch. Here is a stack trace, notice that #10 and #11 do not have the file and line numbers associated with them, everything else does.

 

(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  0x082e0d0f in FLEX_HASH_TABLE::search_bank<TD3::uft_search_stage_params>::check_base_entry_width (this=0x8a88f7c <BM_BaseTest::Iss+65564>,

    base_entry_width=4, req_in=...)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include/ip/flex_hash_table/src/search_bank.h:1119

#5  0x082dd698 in FLEX_HASH_TABLE::search_bank<TD3::uft_search_stage_params>::table_search (this=0x8a88f7c <BM_BaseTest::Iss+65564>, req_in=...,

    rst_out=...)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include/ip/flex_hash_table/src/search_bank.h:717

#6  0x082da27d in FLEX_HASH_TABLE::search_bank<TD3::uft_search_stage_params>::process_bank_req (this=0x8a88f7c <BM_BaseTest::Iss+65564>, req_in=...,

    rst_out=...)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include/ip/flex_hash_table/src/search_bank.h:324

#7  0x082d952d in FLEX_HASH_TABLE::search_stage<TD3::uft_search_stage_params>::process_req (this=0x8a78f60 <BM_BaseTest::Iss>, req=..., rst=...)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include/ip/flex_hash_table/src/search_stage.h:307

#8  0x0833f085 in TD3::fb_uft_ss::process_req (

    this=0x8a78f60 <BM_BaseTest::Iss>, req=..., rst=...)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/ip/flex_hash_table/src/trident3/fb_uft_ss.cc:32

#9  0x082e34b7 in FLEX_HASH_TABLE::search_stages::process_search_req (

    this=0x8c16918, req=..., rst=...)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/include/ip/flex_hash_table/src/search_stages.h:176

#10 0x0833554c in FLEX_HASH_TABLE::flex_hash_table<TD3::fb_l3_search::l3_ht_params>::process_table_req(FLEX_HASH_TABLE::REQ_BUS&, FLEX_HASH_TABLE::RST_BUS&) ()

#11 0x08332de3 in FLEX_HASH_TABLE::flex_hash_table<TD3::fb_l3_search::l3_ht_params>::hash_table_lookup(SchanMsg&, FLEX_HASH_TABLE::flex_hash_table_width_t) ()

#12 0x0833127f in TD3::fb_l3_search::table_lookup (

    this=0x8ab9000 <BM_BaseTest::l3_search>, smsg=..., table_type=3284)

    at /projects/ntsw-arch3/AV/users/runipg/rg_arch2/arch/ip/flex_hash_table/src/trident3/fb_l3_search.cc:310

 

I looked through the object files using “nm” and the executable using “readelf”. These symbols are listed as weak symbols.

 

% readelf -t --wide --symbols test_flex_ht.linux | grep l3_search | grep hash_table_lookup

43328: 08332ca8   810 FUNC    WEAK   DEFAULT   12 _ZN15FLEX_HASH_TABLE15flex_hash_tableIN3TD312fb_l3_search12l3_ht_paramsEE17hash_table_lookupER8SchanMsgNS_23flex_hash_table_width_tE

Just FYI, the object itself lives in a static global store.

 

 

Thanks for looking into it!

 

----

Runip

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]