[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gprof cannot find symbols in a MIPS IRIX a.out
From: |
Anmol Paralkar |
Subject: |
Re: gprof cannot find symbols in a MIPS IRIX a.out |
Date: |
Sun, 21 Dec 2003 22:36:25 +0530 (IST) |
Hi Ian,
Thanks for helping. (Please do see inline).
On Sun, 21 Dec 2003, Ian Lance Taylor wrote:
> Anmol Paralkar <address@hidden> writes:
>
> > I am trying to use gprof on a MIPS IRIX 6.5 box, but gprof seems to be
> > unable
> > to read in the symbols of the executable.
>
> gprof uses the normal symbol table, not the dynamic symbol table.
>
> An executable which uses shared libraries will still normally have a
> normal symbol table, unless you intentionally stripped it for some
> reason.
All the symbols are in the dynamic symbol table, the normal one is empty.
Did both: objdump -[tT] a.out (I have'nt stripped the a.out).
> That isn't very many symbols.
I just included a snippet, to show that the symbols are in the a.out.
Here's the actual list (objdump -T a.out):
--------------------------------------------------------------------------------
a.out: file format elf32-nbigmips
DYNAMIC SYMBOL TABLE:
00000000 l d *ABS* 0000071e .debug_line
00000000 l d *ABS* 000000d2 .debug_pubnames
00000000 l d *ABS* 00000021 .debug_funcnames
00000000 l d *ABS* 000000a0 .debug_aranges
00000000 l d *ABS* 0000019c .debug_frame
00000000 l d *ABS* 00000101 .debug_abbrev
00000000 l d *ABS* 00000451 .debug_info
10000114 l d *ABS* 00000015 .interp
10000130 l d *ABS* 00000080 .MIPS.options
100001b0 l d *ABS* 00000018 .reginfo
100001c8 l d *ABS* 00000108 .dynamic
100002d0 l d *ABS* 00000014 .liblist
100002e4 l d *ABS* 0000025f .dynstr
10000544 l d *ABS* 0000031c .hash
10000860 l d *ABS* 00000450 .dynsym
10000cb0 l d *ABS* 00000045 .MIPS.symlib
10000cf8 l d *ABS* 00000228 .msym
10000f20 l d *ABS* 0000010c .MIPS.stubs
10001030 l d *ABS* 00000a64 .text
10001aa0 l d *ABS* 00000018 .init
10014000 l d *ABS* 0000006e .rodata
10014070 l d *ABS* 00000004 .data
10014074 l d *ABS* 000000a4 .got
10014118 l d *ABS* 00000004 .sdata
1001411c l d *ABS* 00000025 .sbss
10014144 l d *ABS* 00000004 .lit4
10014148 l d *ABS* 00000010 .srdata
10014160 l d *ABS* 00000034 .bss
00000000 g d *ABS* 00000000 .protected __dso_displacement
10000000 g d *ABS* 00000000 .protected __elf_header
10000034 g d *ABS* 00000000 .protected __program_header_table
10000f20 g d *ABS* 00000000 ftext
10000f20 g d *ABS* 00000000 _ftext
10001030 g DF *ABS* 0000010c __start
1000113c g DF *ABS* 0000000c _mcount
10001ab8 g d *ABS* 00000000 _etext
10014000 g d *ABS* 00000000 _fdata
10014000 g d *ABS* 00000000 fdata
10014180 g DO .acommon 00000004 __rld_obj_head
10015000 g d *ABS* 00000000 _fbss
10015000 g d *ABS* 00000000 edata
10015000 g d *ABS* 00000000 fbss
10015000 g d *ABS* 00000000 end
10015000 g d *ABS* 00000000 _end
10015000 g d *ABS* 00000000 _edata
00000000 DO *UND* 00000004 _environ
10000f24 DF *UND* 000000f0 exit
10000f38 DF *UND* 00000008 __readenv_sigfpe
10000f4c DF *UND* 00000144 printf
10000f60 DF *UND* 00000000 sbrk
10000f74 DF *UND* 00000138 write
10000f88 DF *UND* 000000a4 getenv
10000f9c DF *UND* 00000000 getpid
10000fb0 DF *UND* 00000080 sprintf
10000fc4 DF *UND* 00000130 creat
10000fd8 DF *UND* 000001ec perror
10000fec DF *UND* 00000138 close
10001000 DF *UND* 000000e8 atexit
10001014 DF *UND* 00000000 profil
10001154 g DF *ABS* 00000070 main
100011c8 g DF *ABS* 000002c8 monstartup
10001490 g DF *ABS* 0000025c _mcleanup
100016f0 g DF *ABS* 00000328 mcount
10001aac g DF *ABS* 00000004 __istart
10001ab8 g d *ABS* 00000000 etext
10014160 g DO *ABS* 00000004 minbrk
10014170 g DO .acommon 00000004 __Argc
10014190 g DO .acommon 00000004 __Argv
--------------------------------------------------------------------------------
> Are you trying to use gprof to profile
> the functions in the shared library? That won't work unless the
> library itself was compiled with -pg. Even then it probably requires
> support from the shared library, which probably won't happen on an
> Irix system.
> gprof does normally work when using shared libraries, but it normally
> only profiles the functions in the main executable.
Actually, I'm not trying to profile a shared library. The problem is that
by default compilation assumes shared libraries, and so the symbols are
placed in the dynamic symbol table, whereas gprof expects them in the
normal one.
So the change that I made:
> > I also tried making this change in core_init() in gprof/corefile.c:
- was to make a call to bfd_get_dynamic_symtab_upper_bound() and
bfd_canonicalize_dynamic_symtab() instead of the currently existing
bfd_get_symtab_upper_bound() and bfd_canonicalize_symtab().
> > But that does not work either.
>
> Precisely how does it not work? I don't know if that will give you
> correct profiling, but I would not expect you to get the ``no symbol''
> error.
Here's the debugger trace:
________________________________________________________________________________
175 core_num_syms = bfd_get_dynamic_symtab_upper_bound (core_bfd);
(gdb)
176 if (core_num_syms < 0)
(gdb) p core_num_syms
$1 = 276
(gdb) n
183 core_syms = (asymbol **) xmalloc (core_num_syms);
(gdb)
184 core_num_syms = bfd_canonicalize_dynamic_symtab (core_bfd, core_syms);
(gdb) s
_bfd_elf_canonicalize_dynamic_symtab (abfd=0x10114b28, alocation=0x10115bc8) at
elf.c:5650
5650 struct elf_backend_data *bed = get_elf_backend_data (abfd);
(gdb) s
5651 long symcount = bed->s->slurp_symbol_table (abfd, alocation, TRUE);
(gdb) s
bfd_elf32_slurp_symbol_table (abfd=0x10114b28, symptrs=0x10115bc8, dynamic=1)
at elfcode.h:1059
1059 Elf_Internal_Sym *isymbuf = NULL;
(gdb) n
1061 Elf_External_Versym *xverbuf = NULL;
(gdb)
1075 if (! dynamic)
(gdb)
1082 hdr = &elf_tdata (abfd)->dynsymtab_hdr;
(gdb) p dynamic
$2 = 1
(gdb) n
1083 if (elf_dynversym (abfd) == 0)
(gdb) n
1084 verhdr = NULL;
(gdb)
1087 if ((elf_tdata (abfd)->dynverdef_section != 0
(gdb)
1099 ebd = get_elf_backend_data (abfd);
(gdb)
1100 symcount = hdr->sh_size / sizeof (Elf_External_Sym);
(gdb) n
1102 if (symcount == 0)
(gdb) p symcount
$3 = 0
________________________________________________________________________________
Thanks once more for yor help; any inputs you might have are greatly
appreciated.
Regards,
Anmol.
Message not available