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

[Sandeep Joshi]

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
>