This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
find_pc_partial_function may produce the wrong answer
- From: Paul Koning <pkoning at equallogic dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 20 Jul 2005 10:28:14 -0400
- Subject: find_pc_partial_function may produce the wrong answer
I was tracking down a problem in my (modified) gdb, which showed up
when doing callstack tracing by reading the prologue. (mips-tdep can
do that, and in my version it does it most of the time.)
The problem is that find_pc_partial_function is used to find the start
of the function, and it was producing the wrong answer. Specifically,
it produces the wrong answer when the function is in a shared library.
The cause of the problem is that find_pc_partial_function looks up the
symbol in the msymtab, and that contains only external symbols, not
static symbols. The comments in the source code explicitly claim that
it DOES contain static symbols, but "maint print msymtab" clearly
shows that it doesn't. At least not for MIPS shared libraries...
I noticed the disassemble command calls the same function, so I
checked why it seemed to be ok. The difference is that it passes a
pointer to the end_address argument, and that forces the psymtab to be
read which has the right answer.
Well, that's not the whole workaround either. "disassemble" works
correctly if you just open the shared library ("file
usr/lib/libc.so"). But it too does the wrong thing -- starts
disassembling at the previous non-static function start -- when the
function is in a shared library that's mapped when you open the
corefile, via the "set solib-absolute-prefix" machinery.
Help?
paul