Re: [commit] Rename frame_pc_unwind and frame_unwind_id

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jul 16, 2008 at 12:41:12AM +0200, Mark Kettenis wrote:
> If it's easy for you to back it out, I'd appreciate it.  I really
> don't think the new names are an improvement, and they are longer
> makeing the code slightly less readable...

No trouble, so I backed it out.

They're not an improvement in the current case; without the
distinction between inlined and non-inlined frames, there's no need to
distinguish.  They only make sense in the context of inlined frames...

> > I'm interested in your comments (about this patch or the larger one).
> 
> ...but my main concern is that this diff and the larger one change the
> meaning of a frame.  It seems it gets us further away of what I
> consider to be frame.  Please give me a day or so to study the diff a
> bit more, before I give a more detailed reaction.

... which brings us over here.  Thanks for looking at it - I really
appreciate it!

I tried a couple of approaches when I was putting this together, and
frankly, I couldn't find any sensible way to not put the inlined
functions into the normal frame chain.  They have to be frames, or
else everything that looks at a frame has to look at some other
object; we need them most places that we have a frame.  If they're not
in the frame chain, then all the obvious uses of get_prev_frame /
get_next_frame have questionable semantics.

I've already ripped out the ugliest bits of the frame design in my
most recent reworking of this patch; I couldn't see how to get rid of
them the first time but a year later it was clear.  So maybe another
perspective will be able to clean this up further.  Let me know if you
have any questions on the patch; I don't have time right now to write
as much internals documentation for it as I'd like, but I'll explain
any bit that isn't clear.

-- 
Daniel Jacobowitz
CodeSourcery