get_frame_func() VS get_frame_id().code

[Andrew Cagney]

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.

- get_frame_func_by_id
Returns the function start based on the frame ID.  With the first change 
made, this could even be called get_frame_func.

I've attached a proof-of-concept and as such the patch points to a 
number of additional changes (the most obvious being the need for a 
"tramp-frame" that generalizes the technique).

Andrew
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb/attachments/20040305/b58e6b3a/attachment.ksh>