Re: [RFA] Find the most specific symtab

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Oct 20, 2003 at 04:25:28PM +0200, Michal Ludvig wrote:
> Hi,
> when debugging modules in linux kernel one must load symtab from each 
> module using add-symbol-file command. However find_pc_sect_psymtab() 
> returns with the first, usually less specific entry among all psymtabs 
> instead of the newly added one, which leads to a situation where the 
> wrong source file is chosen and therefore the "next", "next", ... 
> stepping is unusable.
> 
> The attached patch modifies find_pc_sect_psymtab() so that it always 
> returns the most specific symtab. Typical debugging session with 
> verbosity tured on now looks like:
> $ ./gdb /share/linux-2.4.21-2-mludvig/vmlinux
> GNU gdb 2003-10-20-cvs
> [...]
> (gdb) add-symbol-file /share/lkm/lkm.o 0xffa00180c0
> add symbol table from file "/share/lkm/lkm.o" at
>         .text_addr = 0xffa00180c0
> (y or n) y
> Reading symbols from /share/lkm/lkm.o...done.
> (gdb) set verbose
> (gdb) l lkm_exit
> More symtabs for PC=0xffffffffa00181b0 found:
>         Ignoring vsyscall.c (vmlinux) PC=0xff802c9400...0xffff60042a
>         Choosing lkm.c (lkm.o) PC=0xffa00180c0...0xffa00181d9
> 55      void
> 56      lkm_exit(void)
> 57      {
> 58        printk(KERN_INFO "Exitting LKM (jiffies=%lu)...\n", jiffies);
> 59        lkm_func(jiffies);
> 60      }
> 61
> (gdb)
> 
> OK for mainline? Or should there be a different approach?

I'm undecided on whether this patch is a good idea.  The best solution
would be to replace texthigh/textlow with a data structure representing
ranges - Jim's posted some suggestions in the past on how to do this,
but it's quite a lot of work.

If this patch goes in please add a comment explaining that it is working
around bugs in the symtab readers and representation.

I don't know how this would affect overlay debugging.  I don't suppose
any of our simulators are capable of overlays?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer