This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: frame cache


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]