Re: GDB not able to debug files(dwarf2.0) loaded using add-symbol-file

["Sandeep Joshi" <sandeepjoshi dot it at gmail dot com>]

Memory layout:
       Entry point: 0x40018000
       0x40018000 - 0x40060000 is .init
       0x40060000 - 0x40259644 is .text
       0x40259650 - 0x40259f78 is __ex_table
       0x40259f78 - 0x4025a278 is .pci_fixup
       0x4025a278 - 0x4025d8f0 is __ksymtab
       0x4025d8f0 - 0x4025ddf0 is __ksymtab_gpl
       0x4025ddf0 - 0x40266070 is __ksymtab_strings
       0x40266070 - 0x40266174 is __param
       0x40268000 - 0x402b8c10 is .data
       0x402b8c20 - 0x402d995c is .bss

add-symbol-file ~/arm-linux-gdb/bin/test_trap4.out 0x83d8



On 12/24/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Fri, Dec 22, 2006 at 09:51:20AM +0530, Sandeep Joshi wrote:
> > The problem is in the way GDB performs symbol lookup using PC. In
> > function 'find_pc_sect_psymtab' gdb is not performing symbol lookup in
> > all the objfiles. If it finds the PC in the range of any partial
> > symtab, it tries to find the partial symtab that contains a symbol
> > whose address is closest to the PC address in that object file only
> > and returns that partial symbol table.
> >
> > Now if the user puts a breakpoint in the file loaded using
> > add-symbol-file, then in function 'find_pc_sect_psymtab' the PC
> > Address might in the range of some psymtab in the first objfile
> > (vmlinux) and the best match in that file is returned. This is
> > happening because the code range of partial symtabs often overlap,
> > mostly if the functions are reordered.
>
> That would slow this already slow function down even further.  What
> does your memory layout look like to create this problem?
>
> --
> Daniel Jacobowitz
> CodeSourcery