[Bug gdb/16157] the function get_pc_function_start (CORE_ADDR pc) maybe inaccurate

["guosheng_gao at realsil dot com.cn" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #3 from ggs334 <guosheng_gao at realsil dot com.cn> ---
look the code in the function get_pc_function_start(CORE_ADDR pc)   
> CORE_ADDR
> get_pc_function_start (CORE_ADDR pc)
> {
> ...........
> ...........
> ...........
> ...........
> ...........
> ...........

>  msymbol = lookup_minimal_symbol_by_pc (pc);
>  if (msymbol)
>    {
>     CORE_ADDR fstart = 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?

-- 
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: <gdb-prs-return-14671-listarch-gdb-prs=sources.redhat.com@sourceware.org>
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: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
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" <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 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: <bug-16157-4717-GOEPBSNfMo@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16157-4717@http.sourceware.org/bugzilla/>
References: <bug-16157-4717@http.sourceware.org/bugzilla/>
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\x16157

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
> 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.