Re: Frame handling

Andrew Cagney
2003-07-01T14:57:12Z

> 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