From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17647 invoked by alias); 8 Dec 2004 06:51:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17392 invoked from network); 8 Dec 2004 06:50:57 -0000 Received: from unknown (HELO smtp011.mail.yahoo.com) (216.136.173.31) by sourceware.org with SMTP; 8 Dec 2004 06:50:57 -0000 Received: from unknown (HELO ?192.168.1.108?) (jjaimon@202.144.95.243 with plain) by smtp011.mail.yahoo.com with SMTP; 8 Dec 2004 06:50:55 -0000 Message-ID: <41B6A44A.8060309@Yahoo.com> Date: Wed, 08 Dec 2004 06:51:00 -0000 From: Jaimon Jose Reply-To: jjaimon@yahoo.com User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: gdb@sources.redhat.com CC: Daniel Jacobowitz Subject: Re: Reading symbols from dynamic symbol table References: <41B68423.9080509@Yahoo.com> <20041208044558.GA2913@nevyn.them.org> In-Reply-To: <20041208044558.GA2913@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00050.txt.bz2 Yes. This is ELF Here is an example. I create a shared library with the following functions. int func3(void) { char *nullptr = 0; printf("func3\n"); *nullptr = '\0'; } int func2(void) { printf("func2\n"); func3(); } extern "C" int func_entry(void) { printf("func_entry\n"); func2(); } I create the sharedlibrary and link to another program that calls func_entry. $>g++ -shared -o libprgshared.so prgshared.cpp $>nm --defined-only libprgshared.so 00001aa0 A __bss_start 00000740 t call_gmon_start 00001aa0 b completed.1 00001a70 d __CTOR_END__ 00001a6c d __CTOR_LIST__ 00000890 t __do_global_ctors_aux 00000770 t __do_global_dtors_aux 00001900 d __dso_handle 00001a78 d __DTOR_END__ 00001a74 d __DTOR_LIST__ 00001984 A _DYNAMIC 00001aa0 A _edata 00001aa4 A _end 000008c4 T _fini 000007e0 t frame_dummy 00001980 r __FRAME_END__ 0000086c T func_entry 00001a80 A _GLOBAL_OFFSET_TABLE_ 000006f8 T _init 00001a7c d __JCR_END__ 00001a7c d __JCR_LIST__ 00001904 d p.0 0000084e T _Z5func2v 00000828 T _Z5func3v $>g++ -O2 -o prgmain prgmain.cpp libprgshared.so $>./prgmain $>gdb ./prgmain core (gdb) where #0 0x40018848 in func3 () from libprgshared.so #1 0x40018869 in func2 () from libprgshared.so #2 0x40018887 in func_entry () from ibprgshared.so #3 0x080485ca in main () Now I create the shared object with --retain-symbols-file by just exporting only func_entry $>g++ -shared -o libprgshared.so -Wl,--retain-symbols-file -Wl,prgshared.sym prgshared.cpp $>nm --defined-only libprgshared.so 0000086c T func_entry $>nm -D --defined-only libprgshared.so 00001aa0 A __bss_start 00001984 A _DYNAMIC 00001aa0 A _edata 00001aa4 A _end 000008c4 T _fini 0000086c T func_entry 00001a80 A _GLOBAL_OFFSET_TABLE_ 000006f8 T _init 0000084e T _Z5func2v 00000828 T _Z5func3v I link this against my main program and look at the new core file. (gdb) where #0 0x40018848 in ?? () from libprgshared.so #1 0x40018869 in ?? () from libprgshared.so #2 0x40018887 in func_entry () from libprgshared.so #3 0x080485ca in main () Frame #0 and #1 no longer shows the function name though it is available in the dynamic section of shared library. How do I force gdb to read symbols from this section? I'm using the following versions of programs $>ld -V GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux) Supported emulations: elf_i386 i386linux elf_x86_64 $>gdb --version GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc $>>gcc --version gcc (GCC) 3.3.3 (SuSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. thanks, --jaimon Daniel Jacobowitz wrote the following on 12/08/2004 10:15 AM: > On Wed, Dec 08, 2004 at 10:03:39AM +0530, Jaimon Jose wrote: > >>I have few libraries built with --retain-symbols-file ld option. I >>can't see the correct symbols when I open the core file due to this. It >>always shows the stack trace with few exported symbols+offset. However, >>'nm' is able to read all the symbols from dynamic symbol table. Is >>there a way to instruct gdb to read symbols from dynamic symbol table? > > > It normally does - is this ELF? You'll have to investigate why it > isn't working. >