Re: get_frame_func() VS get_frame_id().code

[Daniel Jacobowitz <drow@false.org>]

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?  The only current use
of frame_func_unwind that I see outside of unwinders is the
implementation of get_frame_func.  So we could define frame_func_unwind
to attempt to find the beginning of the function at the unwound PC
using the symtab.

It is already the unwinder's duty to propogate the function address
into the ID.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer