`chain-frame'

`chain-frame'

[Andrew Cagney]

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.

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

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

sigtramp-frame:
Corresponds to a signal trampoline.

fake-frame (?):
Recently discussed, would also use dwarf2cfi but with fake debug 
information.


Andrew

Re: `chain-frame'

[Daniel Jacobowitz]

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

Re: `chain-frame'

[Andrew Cagney]

> 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

Re: `chain-frame'

[Daniel Jacobowitz]

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

Re: `chain-frame'

[Andrew Cagney]

> Great.  (Sentinel btw).

Thanks, mozilla (or at least this version) still doesn't have a spelling 
checker :-(

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

And another one, they just keep comming:

libunwind-frame:

That -lunwind library code that is lurking in the wings (for the ia64 
but it is apparently generic).  The last time I saw the patch it had its 
paws all over the ia64 code.  That is no longer necessary.  It, to, can 
be a separate module.

Andrew

Re: `chain-frame'

[Andrew Cagney]

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

If I was ever granted a wish allowing me to change one (pair) of gdb 
commands, up/down would be it.

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

Er, actually, I've, hopefully, got a beter idea:

	extras-frame

It reflects how the original frame code would use INIT_EXTRA_FRAME_INFO 
during initialization.

Thing is, the phrase `frame chain' is just too useful when describing 
the [er] frame chain (all the frames strung together).

Andrew

Re: `chain-frame'

[Daniel Jacobowitz]

On Fri, Jan 10, 2003 at 10:47:09AM -0500, Andrew Cagney wrote:
> 
> >>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.
> 
> If I was ever granted a wish allowing me to change one (pair) of gdb 
> commands, up/down would be it.

Lord, yes.  Well, maybe that and "until".... :)

> >>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.
> 
> Er, actually, I've, hopefully, got a beter idea:
> 
> 	extras-frame
> 
> It reflects how the original frame code would use INIT_EXTRA_FRAME_INFO 
> during initialization.
> 
> Thing is, the phrase `frame chain' is just too useful when describing 
> the [er] frame chain (all the frames strung together).

I don't like "extras-frame" - it has no context outside of the
mechanism, which will hopefully go away, right?  But this kind of frame
isn't going to go away, since we have to cope without CFI data.

saved-frame-chain?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: `chain-frame'

[Andrew Cagney]

>> Er, actually, I've, hopefully, got a beter idea:
>> 
>> 	extras-frame
>> 
>> It reflects how the original frame code would use INIT_EXTRA_FRAME_INFO 
>> during initialization.
>> 
>> Thing is, the phrase `frame chain' is just too useful when describing 
>> the [er] frame chain (all the frames strung together).
> 
> 
> I don't like "extras-frame" - it has no context outside of the
> mechanism, which will hopefully go away, right?  But this kind of frame
> isn't going to go away, since we have to cope without CFI data.

True.  On the other hand, no one, other than the GDB developer is going 
to know about it, and it reflects the underlying implementation, so I 
don't know that it needs any additional context.

As for it going away, actually, yes it will.  New architectures will 
hopefully want to implement the three unwind methods directly.  It 
should lead to a more efficient implementation.  See my post to JimI 
(cc'd gdb@).

> saved-frame-chain?

That's got the same problem as `saved-regs-frame'.  Every frame has a 
saved frame chain ...

Andrew

Re: `chain-frame'

[Daniel Jacobowitz]

On Fri, Jan 10, 2003 at 11:17:49AM -0500, Andrew Cagney wrote:
> 
> >>Er, actually, I've, hopefully, got a beter idea:
> >>
> >>	extras-frame
> >>
> >>It reflects how the original frame code would use INIT_EXTRA_FRAME_INFO 
> >>during initialization.
> >>
> >>Thing is, the phrase `frame chain' is just too useful when describing 
> >>the [er] frame chain (all the frames strung together).
> >
> >
> >I don't like "extras-frame" - it has no context outside of the
> >mechanism, which will hopefully go away, right?  But this kind of frame
> >isn't going to go away, since we have to cope without CFI data.
> 
> True.  On the other hand, no one, other than the GDB developer is going 
> to know about it, and it reflects the underlying implementation, so I 
> don't know that it needs any additional context.
> 
> As for it going away, actually, yes it will.  New architectures will 
> hopefully want to implement the three unwind methods directly.  It 
> should lead to a more efficient implementation.  See my post to JimI 
> (cc'd gdb@).

Maybe legacy-chain or generic-chain?   Hmm, I kind of like
generic-chain.  Then the architecture can provide arch-chain.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: `chain-frame'

[Andrew Cagney]

> Maybe legacy-chain or generic-chain?   Hmm, I kind of like
> generic-chain.  Then the architecture can provide arch-chain.

I think generic frame is to close to generic dummy frames (and the're 
not generic :-)  I was going to say ya, to legacy frames, but I think 
we're going to end up with multiple legacy frames, however, ...

Andrew