From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10276 invoked by alias); 12 Nov 2013 11:46:24 -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 10242 invoked by uid 48); 12 Nov 2013 11:46:23 -0000 From: "palves at redhat dot com" 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 11:46: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: palves at redhat dot com 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: bug_status cc 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/msg00294.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16157 Pedro Alves changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING CC| |palves at redhat dot com --- Comment #1 from Pedro Alves --- > get_pc_function_start(CORE_ADDR pc) try to get the function start for a > special pc, but the function > lookup_minimal_symbol_by_pc(CORE_ADDR pc) may return a minimal_symbol, which > is not a function(e.g. a label in assembler code). So the fstart is not a > function start address, too. The only way to tell apart a label from a function, is from the minimal symbol's size. Try stepping through lookup_minimal_symbol_by_pc_section_1, and see the comments there. > This may cause a problem: in following code, GDB can not stop when try to next > over Line 1.(lop2 and lop3 are mistaken for a function, so GDB thinks that it > step into a new function, set a breakpoint at the address stored in register > $ra, and run to it) 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. I wonder if this related to the outermost heuristics, or something odd in the unwinder/backtrace. What does "bt" show when the program is stopped at the instruction just before lop2, and then again "bt" when you stepi to lop2? -- You are receiving this mail because: You are on the CC list for the bug.