think-o: frame.c:find_saved_register() frame1 = get_prev_frame (frame1) backwards?

think-o: frame.c:find_saved_register() frame1 = get_prev_frame (frame1) backwards?

[Andrew Cagney]

Hello,

The function frame.c:find_saved_register() contains the code:

   /* Note that this next routine assumes that registers used in
      frame x will be saved only in the frame that x calls and
      frames interior to it.  This is not true on the sparc, but the
      above macro takes care of it, so we should be all right. */
   while (1)
     {
       QUIT;
       frame1 = get_prev_frame (frame1);
       if (frame1 == 0 || frame1 == frame)
	break;
       FRAME_INIT_SAVED_REGS (frame1);
       if (frame1->saved_regs[regnum])
	addr = frame1->saved_regs[regnum];
     }

(it dates back to prior to Red Hats CVS repository).  I think this is 
going the wrong way, looking in frame.h the doco indicates:

     /* Pointers to the next (down, inner) and previous (up, outer)
        frame_info's in the frame cache.  */
     struct frame_info *next; /* down, inner */
     struct frame_info *prev; /* up, outer */

and blockframe.c:get_prev_frame() returns the next ``up, outer'':

   /* If we have the prev one, return it */
   if (next_frame->prev)
     return next_frame->prev;

Given:

	a() { b (); }

then it is b() that is saving registers used by a().  And b() is ``down, 
inner''.

confused,
Andrew

Re: think-o: frame.c:find_saved_register() frame1 = get_prev_frame (frame1) backwards?

[Kevin Buettner]

On Feb 12,  2:46pm, Andrew Cagney wrote:

> (it dates back to prior to Red Hats CVS repository).  I think this is 
> going the wrong way, looking in frame.h the doco indicates:
> 
>      /* Pointers to the next (down, inner) and previous (up, outer)
>         frame_info's in the frame cache.  */
>      struct frame_info *next; /* down, inner */
>      struct frame_info *prev; /* up, outer */
> 
> and blockframe.c:get_prev_frame() returns the next ``up, outer'':
> 
>    /* If we have the prev one, return it */
>    if (next_frame->prev)
>      return next_frame->prev;
> 
> Given:
> 
> 	a() { b (); }
> 
> then it is b() that is saving registers used by a().  And b() is ``down, 
> inner''.
> 
> confused,
> Andrew

I don't know.  I've also gotten confused when staring at this code.  I
don't find the terms "next", "down", or "inner" to be helpful at all
when trying to figure it out either.  I think we ought to be referring
to "callers" and "callees".

Kevin

Re: think-o: frame.c:find_saved_register() frame1 = get_prev_frame (frame1) backwards?

[Daniel Jacobowitz]

On Fri, Feb 15, 2002 at 03:50:41PM -0700, Kevin Buettner wrote:
> On Feb 12,  2:46pm, Andrew Cagney wrote:
> 
> > (it dates back to prior to Red Hats CVS repository).  I think this is 
> > going the wrong way, looking in frame.h the doco indicates:
> > 
> >      /* Pointers to the next (down, inner) and previous (up, outer)
> >         frame_info's in the frame cache.  */
> >      struct frame_info *next; /* down, inner */
> >      struct frame_info *prev; /* up, outer */
> > 
> > and blockframe.c:get_prev_frame() returns the next ``up, outer'':
> > 
> >    /* If we have the prev one, return it */
> >    if (next_frame->prev)
> >      return next_frame->prev;
> > 
> > Given:
> > 
> > 	a() { b (); }
> > 
> > then it is b() that is saving registers used by a().  And b() is ``down, 
> > inner''.
> > 
> > confused,
> > Andrew
> 
> I don't know.  I've also gotten confused when staring at this code.  I
> don't find the terms "next", "down", or "inner" to be helpful at all
> when trying to figure it out either.  I think we ought to be referring
> to "callers" and "callees".

While they may not be 100% accurate (call dummies for instance, signal
handlers...) I strongly agree.  That's a much clearer term.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: think-o: frame.c:find_saved_register() frame1 = get_prev_frame (frame1) backwards?

[Andrew Cagney]

> I don't know.  I've also gotten confused when staring at this code.  I
>> don't find the terms "next", "down", or "inner" to be helpful at all
>> when trying to figure it out either.  I think we ought to be referring
>> to "callers" and "callees".
> 
> 
> While they may not be 100% accurate (call dummies for instance, signal
> handlers...) I strongly agree.  That's a much clearer term.

I've kind of grown familar with inner and outer - try thinking of 
``inner most frame'' or ``outer most frame''.  I agree that up/down and 
next/prev are a walking disaster.

Andrew