From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19508 invoked by alias); 12 Nov 2013 13:01:30 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 19484 invoked by uid 48); 12 Nov 2013 13:01:30 -0000 From: "guosheng_gao at realsil dot com.cn" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: guosheng_gao at realsil dot com.cn X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q4/txt/msg00295.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16157 --- Comment #2 from ggs334 --- > "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.