Re: frame cache

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jul 24, 2007 at 11:10:01AM -0700, Michael Eager wrote:
> This seems odd.  The function is <target>_analyze_prologue()
> not <target>_analyze_part_of_a_prologue().  The prologue isn't going
> to change depending on where the program stopped.  <target>_skip_prologue()
> can return a pc based on whatever a complete analysis reveals.
> 
> In i386, for example, the "pc limit" (called current_pc) passed
> to i386_analyze_prologue() is 0xffffffff.  Sparc is similar.
> Neither seem to restrict how far the analyze_prologue function scans.

Yes.  But when you are analyzing the prologue for a frame cache, it is
important to restrict it to the current PC.  Otherwise obviously bad
things happen when you're stopped on the first or second instruction
of the function.  So the result of that analysis is not always the
same for a given function.

> I do see that some targets merge skip_prologue and analyze_prologue.
> Are there other methods?  It would seem to me that for any function
> that has DWARF data, one can locate the end of the prologue without
> reading data from the target.  I don't see any target which does this.

Some targets found it easier to have two separate methods.  Others use
line number info, or some combination - e.g. mips_skip_prologue ->
skip_prologue_using_sal.  Nothing tries to use the .debug_line
prologue flag, since GCC doesn't generate it yet.

-- 
Daniel Jacobowitz
CodeSourcery