Re: Frame handling

["Jafa" <jafa@silicondust.com>]

Hi Andrew,

>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).

Yeah, that was a bit of a mess :-)

>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).

Makes sense.... the trick is to leave this power to the port-specific code.

The proposal in my last email still allows the port-writer to implement a
light-weight frame_chain but I have to admit that it doesn't point them in
that direction.

Thanks for your time BTW - My view of the world is pretty small.

Nick