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

["palves at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |palves at redhat dot com

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