This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: `chain-frame'
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