Re: `chain-frame'

[Andrew Cagney <ac131313@redhat.com>]

> I'm trying, but I still don't quite see how you're laying this out. 
> All help welcomed!  Maybe I should look over your WIP again; has it
> changed since you last posted it?

It's changed.  I'm going to cut a branch.

> regcache-frame (regs-frame?):
>> A frame that maps directly onto the register cache.
> 
> 
> Doesn't unwind, since we're at the top.

Nope!  At the bottom, and it does unwind.

This unwinds to the ``inner most frame''.  Instead of calling 
create_new_frame(), get_current_frame() creates this frame and then 
unwinds it.

If get_current_frame()'s attempt at unwinding this frame fails.  A fake 
frame is created (or even the regs-frame) and returned  This guarentees 
that `there is always a frame'.

For the moment it unwinds the FP/PC using read_fp() and read_pc(), and 
the registers by reading the register cache.  Eventually, it can use 
methods that: don't suffer from decr-pc-after-break; don't assume global 
state; and also refer to the thread's stop reason when determining the 
pc/fp.

Another name for this one is:

	sentinal-frame

since it acts as the sentinal one beyond the inner most frame.

> fake-frame (?):
>> Recently discussed, would also use dwarf2cfi but with fake debug 
>> information.
> 
> 
> Unwinds using the CFI reader and fake DWARF-2 CFI information.  Someday
> maybe have a more generalized "unwind language"; that's my hope,
> anyway.  So we don't have to encode and decode the CFI gunk.

Yes, and Yes.  The later can just plug in.

> And the other group of frames just use the current frame chain code,
> and poke at the stack to find the saved registers; maybe
> "stack-chain-frame"?

Oops, yes.  Just:

	chain-frame:

though I think.

Andrew