This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Find the most specific symtab
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michal Ludvig <mludvig at suse dot cz>
- Cc: GDB Patches <gdb-patches at sources dot redhat dot com>
- Date: Mon, 20 Oct 2003 10:30:57 -0400
- Subject: Re: [RFA] Find the most specific symtab
- References: <3F93F058.5060104@suse.cz>
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