Frame handling

[Andrew Cagney]

> Um, this is still dangling.  Can you please express your question using 
>> terminology consistent with the frame unwind code.
> 
> 
> I think Nick's question is: why does every architecture implement the
> cache lazily, instead of GDB instructing the architecture when to
> create the cache.

(I'm honestly not so sure, I think there is more).

For this question, it's a case of learning from past mistakes.  See 
legacy_get_prev_frame.

The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed. 
General confusion over what was ment to happen when quickly exploded 
into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC, 
INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to 
initialize the cache[s] (there ended up being three!) but many, such as 
FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they 
didn't even have access to the cache).

The new code takes the oposite approach.  Only specify interfaces that 
are absolutly needed and make the unwinder 100% responsible for all 
cache management, populating it based on the immediate demand.

One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing 
prologue analysis).  It may be possible to implement this in the new 
unwinders - id_unwind would only create/populate what was immediatly 
necessary and avoid a full prologue analysis (something that is 
considered expensive).

Andrew