This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]