Re: Revamped frame chain, useful for PPC?

[Jim Ingham <jingham at apple dot com>]

Andrew,

Yeah, what I did was actually pretty minimal; I just added an mi 
command that walked the stack and returned frame & pc pairs.  It 
operated outside of the ordinary gdb frame chain.  This is inefficient 
in that we don't get to use ANY of this work if the user asks for 
something higher up on the stack, but was good enough for our purposes. 
 PB runs the new mi command when it gets a stopped message, and doesn't 
refetch any stack frames that match the return.  Since most of the time 
people are interested in seeing the stack, but don't really visit 
anything higher that the last couple of frames, we never end up 
constructing the real gdb frame chain until something actually changes.

I have been watching your work to provide a better way of doing this, 
and look forward to being able to use it.

We are in the throes or planning for our next release, which means many 
meetings, no real work...  Once we have decided the big items, I will 
arrange time to incorporate this (it should be a fairly small piece of 
work.)

Thanks for pointing this out.

Jim

On Friday, January 10, 2003, at 07:54  AM, Andrew Cagney wrote:

> Jim,
>
> Long long ago you mentioned that, to improve performance, you hacked 
> the PPC code and core GDB so that it could do a light weight frame 
> chain. That is, instead of a full frame prologue (aka, init frame 
> saved regs / init extra frame info), it would just chain the frame 
> pointer.
>
> Can I suggest looking at the cagney-unwind-20030108-branch as it 
> contains the revamped unwind mechanism.  In particular, it now leaves 
> it to the target architecture to determine if/when additional prologue 
> analysis should be performed.
>
> See the function get_prev_frame() for the unwind sequence, and 
> sentinel-frame / dummy-frame for specific frame implementations.
>
> Andrew
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer