This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/16157] the function get_pc_function_start (CORE_ADDR pc) maybe inaccurate
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 12 Nov 2013 14:26:46 +0000
- Subject: [Bug gdb/16157] the function get_pc_function_start (CORE_ADDR pc) maybe inaccurate
- Auto-submitted: auto-generated
- References: <bug-16157-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16157
--- 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.