This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: get_frame_func() VS get_frame_id().code
On Fri, Mar 05, 2004 at 11:05:54AM -0500, Andrew Cagney wrote:
Hello,
The current get_frame_func() is implemented as roughly:
fi->prev_func.addr = get_pc_function_start (addr_in_block);
Unfortunatly this isn't valid for a signal trampoline (or at least the
evil ones that consist of random bytes in a random memory location).
For such trampolines, get_pc_function_start [rightly] fails and "func"
ends up as zero -- not good -- a properly constructed frame ID requires
non-zero code and stack addresses.
Fortunatly, with a bit of extra instruction pattern matching, it is
possible to identify the first instruction of a signal trampoline and
hence correctly compute the trampolines "func" address. Similarly, more
normal frames can determine the function start using the symbol table's
get_pc_function_start.
Consequently, I think there should be mechanism for obtaining both the
symbol table and frame's idea of a function's start address. This would
mean introducing:
- get_frame_func_by_symtab
Returns the function start according to the symbol table. Much of the
existing code (especially unwinders) would need to be updated to use this.
How about just leaving this as frame_func_unwind?
Because the func, based on the frame ID, is more likely to be correct.
The current get_frame_func and frame_func_unwind can return 0 or the
wrong function :-(
BTW, there is get_frame_function() which returns the symbol for the
function.
> The only current use
> of frame_func_unwind that I see outside of unwinders is the
> implementation of get_frame_func.
... get_frame_func is hardly called ...
> So we could define frame_func_unwind
> to attempt to find the beginning of the function at the unwound PC
> using the symtab.
... so it may even be possible to simply pull get_frame_func from the
frame interface.
It is already the unwinder's duty to propogate the function address
into the ID.
Andrew