public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "guosheng_gao at realsil dot com.cn" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/16157] the function get_pc_function_start (CORE_ADDR pc) maybe inaccurate
Date: Tue, 12 Nov 2013 13:01:00 -0000	[thread overview]
Message-ID: <bug-16157-4717-bYLpUqYFHT@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-16157-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=16157

--- Comment #2 from ggs334 <guosheng_gao at realsil dot com.cn> ---
> "bt" show when the program is stopped at the instruction just before lop2:
#0  _start () at crt0.S:93
> then stepi
(gdb) si
warning: GDB can't find the start of the function at 0xfffffffc.

> and then again "bt" when stepi to lop2?
#0  lop2 () at crt0.S:95
#1  0xfffffffe in ?? ()

> Sounds like something else might be tricking GDB into thinking you stepped 
> into a new function.  See the code just below "Check for subroutine calls." 
> part of infrun.c.  That's where the logic to detect if the program called a 
> new function is.

GDB use the frame id to "Check for subroutine calls", and the function
frame_id_eq() will check the .code_addr,If .code addresses are
different, the frames are different. If lop3 and lop2 are mistaken for function
start address, the code address are different. So GDB thinking the program
stepped into a new function

gdb/frame.c:
int
frame_id_eq (struct frame_id l, struct frame_id r)
{
  int eq;

  if (!l.stack_addr_p && l.special_addr_p
      && !r.stack_addr_p && r.special_addr_p)
    /* The outermost frame marker is equal to itself.  This is the
       dodgy thing about outer_frame_id, since between execution steps
       we might step into another function - from which we can't
       unwind either.  More thought required to get rid of
       outer_frame_id.  */
    eq = 1;
  else if (!l.stack_addr_p || !r.stack_addr_p)
    /* Like a NaN, if either ID is invalid, the result is false.
       Note that a frame ID is invalid iff it is the null frame ID.  */
    eq = 0;
  else if (l.stack_addr != r.stack_addr)
    /* If .stack addresses are different, the frames are different.  */
    eq = 0;
  else if (l.code_addr_p && r.code_addr_p && l.code_addr != r.code_addr)
    /* An invalid code addr is a wild card.  If .code addresses are
       different, the frames are different.  */
    eq = 0;
  else if (l.special_addr_p && r.special_addr_p
       && l.special_addr != r.special_addr)
    /* An invalid special addr is a wild card (or unused).  Otherwise
       if special addresses are different, the frames are different.  */
    eq = 0;
  else if (l.artificial_depth != r.artificial_depth)
    /* If artifical depths are different, the frames must be different.  */
    eq = 0;
  else
    /* Frames are equal.  */
    eq = 1;

  if (frame_debug)
    {
      fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l=");
      fprint_frame_id (gdb_stdlog, l);
      fprintf_unfiltered (gdb_stdlog, ",r=");
      fprint_frame_id (gdb_stdlog, r);
      fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", eq);
    }
  return eq;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.


  parent reply	other threads:[~2013-11-12 13:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  6:12 [Bug gdb/16157] New: " guosheng_gao at realsil dot com.cn
2013-11-12 11:46 ` [Bug gdb/16157] " palves at redhat dot com
2013-11-12 13:01 ` guosheng_gao at realsil dot com.cn [this message]
2013-11-12 13:18 ` guosheng_gao at realsil dot com.cn
2013-11-12 14:29 ` palves at redhat dot com
2013-11-13  2:49 ` guosheng_gao at realsil dot com.cn
2013-11-13  3:10 ` guosheng_gao at realsil dot com.cn
2013-11-13 10:06 ` palves at redhat dot com
2013-11-14  9:57 ` guosheng_gao at realsil dot com.cn

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=bug-16157-4717-bYLpUqYFHT@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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).