This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: `chain-frame'
On Wed, Jan 08, 2003 at 10:06:12PM -0500, Andrew Cagney wrote:
> >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.
Oh, er. Right, I should have understood that by now. Thank you.
> Another name for this one is:
>
> sentinal-frame
>
> since it acts as the sentinal one beyond the inner most frame.
Great. (Sentinel btw).
> >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.
This'll require playing around with my vocabulary a little to get used
to it, but I can buy it. The general action is "unwinding"; looking
for the "chain" is one mechanism. I like it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer