Re: `chain-frame'

[Daniel Jacobowitz <drow@mvista.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?

I think I understand now why you want fake-frame different from
cfi-frame.  I'll probably wrap my head around it better when I take a
good look at the code, eventually.

On Wed, Jan 08, 2003 at 09:09:57PM -0500, Andrew Cagney wrote:
> I've been looking for a better name for the mechanism the targets 
> currently use when unwinding a frame.  I've been using saved-regs frame, 
> but that is pretty pervasive - all frames contain saved regs.
> 
> I'm thinking of instead calling it a `chain-frame' since the existing 
> mechanism relies not just on the frame->saved_regs[] array but also the 
> FRAME_CHAIN() method.
> 
> This means that there are so far potentially:
> 
> dummy-frame:
> Created when doing an inferior function call.

Unwinds from the dummy register cache...

> regcache-frame (regs-frame?):
> A frame that maps directly onto the register cache.

Doesn't unwind, since we're at the top.

> cfi-frame:
> Implemented using dwarf2cfi (this is the holy grail)

Unwinds using the CFI reader and the DWARF-2 CFI data.

> sigtramp-frame:
> Corresponds to a signal trampoline.

Unwinds using the sigtramp handler.

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

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"?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer