From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28589 invoked by alias); 12 Nov 2013 13:18:17 -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 28548 invoked by uid 48); 12 Nov 2013 13:18:17 -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:18: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: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q4/txt/msg00296.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D16157 --- Comment #3 from ggs334 --- look the code in the function get_pc_function_start(CORE_ADDR pc)=20=20=20 > CORE_ADDR > get_pc_function_start (CORE_ADDR pc) > { > ........... > ........... > ........... > ........... > ........... > ........... > msymbol =3D lookup_minimal_symbol_by_pc (pc); > if (msymbol) > { > CORE_ADDR fstart =3D SYMBOL_VALUE_ADDRESS (msymbol); > if (find_pc_section (fstart)) > return fstart; > } > return 0; >} the label lop2 and lop3 hava adress values, if the pc value is equal to the address of lop2 or lop3, the msymbol returned from lookup_minimal_symbol_by_pc() must be lop2 or lop3, then uses SYMBOL_VALUE_ADDRESS (msymbol) to get the address, and treats the address as function start address. I Think this is the problem, is it accurate? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From gdb-prs-return-14671-listarch-gdb-prs=sources.redhat.com@sourceware.org Tue Nov 12 14:26:48 2013 Return-Path: Delivered-To: listarch-gdb-prs@sources.redhat.com Received: (qmail 8808 invoked by alias); 12 Nov 2013 14:26:48 -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 Delivered-To: mailing list gdb-prs@sourceware.org Received: (qmail 8778 invoked by uid 48); 12 Nov 2013 14:26:47 -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 14:26: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: 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/msg00297.txt.bz2 Content-length: 1881 https://sourceware.org/bugzilla/show_bug.cgi?id=16157 --- Comment #4 from Pedro Alves --- > the code address are different. So GDB thinking the program stepped into a new > function That's not sufficient, the frame that was frame #0 before the step must be frame #1 after the step for GDB to consider this was a subroutine call. That's this part of the condition: && (frame_id_eq (frame_unwind_caller_id (get_current_frame ()), ecs->event_thread->control.step_stack_frame_id) If before the stepi you have: #0 _start () at crt0.S:93 and then after you have: #0 lop2 () at crt0.S:95 #1 0xfffffffe in ?? () Then I don't understand how that frame_id_eq returned true. Well, unless both were outer_frame_id. Please check that. I also don't understand why GDB thinks the function is _start just before the stepi, instead of lop3. What's different between lop3 and lop2? You need to step through lookup_minimal_symbol_by_pc_section_1 and understand that. > the label lop2 and lop3 hava adress values, if the pc value is equal to the > address of lop2 or lop3, the msymbol returned from > lookup_minimal_symbol_by_pc() must be lop2 or lop3, then uses > SYMBOL_VALUE_ADDRESS (msymbol) to get the address, and treats the address as > function start address. > I Think this is the problem, is it accurate? Not exactly. lookup_minimal_symbol_by_pc, if not returning the "real" function, then should be returning the closes label. That is, for all instructions between lop3 and lop2, it should return lop3, etc. But that shouldn't be a problem on its own, the other checks in the "Check for subroutine calls" bit should catch that. Unless, again, this is really the outer_frame_id bits triggering. outer_frame_id really should die... -- You are receiving this mail because: You are on the CC list for the bug.