public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Paul Koning <pkoning@equallogic.com>
To: gdb@sources.redhat.com
Subject: find_pc_partial_function may produce the wrong answer
Date: Wed, 20 Jul 2005 14:28:00 -0000	[thread overview]
Message-ID: <17118.24446.528000.56862@gargle.gargle.HOWL> (raw)

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

             reply	other threads:[~2005-07-20 14:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-20 14:28 Paul Koning [this message]
2005-07-20 14:33 ` Daniel Jacobowitz
2005-07-20 15:38   ` Paul Koning
2005-07-20 16:17     ` H. J. Lu
2005-07-20 16:24       ` Paul Koning
2005-07-20 17:09   ` Paul Koning
2005-07-20 17:13     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17118.24446.528000.56862@gargle.gargle.HOWL \
    --to=pkoning@equallogic.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).